Unix时间戳转换器做什么（为什么你需要它）
Unix时间戳转换器的作用，是在人类可读的日期和自1970年1月1日 00:00:00 UTC（即"Unix纪元"）以来的秒数之间进行转换。此刻我写这篇文章的时候，时间戳大约是1,780,000,000。这个数字每秒增加1，从不重置，也不关心时区、夏令时或闰年。它是表示某一时刻最简单的方式。
开发者为什么需要转换器？因为人类的思维方式是"2026年6月4日下午3:30"，而计算机的思维方式是1780646400。每个API、数据库和日志文件都使用其中一种格式（或两种都用）。手动转换需要知道时区偏移量、当前是否处于夏令时，以及每个月有多少秒。或者你可以直接使用转换工具，毫秒级获得答案。
Unix纪元（1970年1月1日）是贝尔实验室的Unix创建者随意选择的，没有任何天文学或历史意义。其他系统使用不同的纪元：Windows FILETIME从1601年1月1日开始计算100纳秒间隔。macOS Cocoa从2001年1月1日开始计算秒数。GPS时间从1980年1月6日开始计算周数和秒数。在这些系统之间转换需要同时知道纪元起点和计量单位。
秒 vs 毫秒（Bug来源第一名）
Unix时间戳传统上以秒为单位。JavaScript的Date.now()返回毫秒。Java的System.currentTimeMillis()返回毫秒。Python的time.time()返回秒（浮点数）。这种不一致性不断地制造bug。如果你看到时间戳1780646400，它是秒（2026年6月）。如果你看到1780646400000，它是毫秒（同一时刻）。如果你不小心把毫秒当作秒处理，你会得到公元58400年的日期。
快速判断方法：如果数字有10位，它是秒（有效范围2001年到2286年）。如果有13位，它是毫秒（有效范围2001年到2286年）。如果有16位，它是微秒（Python的datetime.timestamp()带微秒精度）。我们的timestamp-converter工具会根据位数自动检测单位。
我的原则：始终以毫秒存储时间戳（或使用ISO 8601字符串格式）。毫秒提供亚秒级精度，同时避免了小数秒的浮点数问题。每种现代语言都能处理64位整数，所以存储成本是一样的。在与使用秒的API交互时，在边界处乘以/除以1000——不要让混合单位在你的代码库中扩散。
我在2021年踩过的一个坑：一个支付系统以秒为单位存储"created_at"，但webhook验证用毫秒检查"时间戳在当前时间5分钟以内"。检查总是失败，因为差值是1,780,000,000,000毫秒（秒级时间戳被当作毫秒解释=公元58400年）减去当前时间。花了3个小时才找到原因，因为错误信息只说了"timestamp expired"。
每个开发者都会踩的时区坑
最常见的时区bug：存储本地时间时不带时区信息。如果你的数据库里有"2026-06-04 15:30:00"——这是UTC？东部时间？服务器所在的时区？如果服务器迁移到不同时区（或你迁移到另一个云区域），所有时间戳都会偏移。永远存储UTC，只在展示时才转换为本地时间。
夏令时会制造出不可能存在的时间和二义性时间。2024年11月3日凌晨2:00东部时间，时钟回拨到1:00 AM。"1:30 AM"这个时间出现了两次。2024年3月10日凌晨2:00，时钟跳到3:00 AM。"2:30 AM"这个时间根本不存在。如果你的调度系统在春季跳钟那天创建了一个2:30 AM的事件，会怎样？大多数系统会静默地移到3:30 AM。有些会直接崩溃。
"日期边界"bug："今天的订单"在不同时区意味着不同的东西。如果你的服务器在UTC时区，而加州的用户在太平洋时间晚上11点（UTC次日早上7点）下单，这笔订单会出现在"明天的"报表里。解决办法：始终按用户本地日期边界转换为UTC来过滤。存储用户的时区（使用IANA格式如"America/Los_Angeles"，而不是UTC偏移量——偏移量无法处理夏令时变化）。
JavaScript的Date对象感知时区但很容易让人困惑。new Date("2026-06-04")解析为UTC午夜，但new Date("2026-06-04T00:00:00")解析为本地时间。new Date(2026, 5, 4)使用本地时间（而且月份从0开始，所以5=六月）。这种不一致造成的bug比JavaScript任何其他API都多。建议使用Temporal API（Stage 3，可通过polyfill使用）或date-fns等库来进行明确的时区处理。
// JavaScript中的时区陷阱
new Date("2026-06-04"); // UTC午夜
new Date("2026-06-04T00:00:00"); // 本地午夜（不一样！）
new Date(2026, 5, 4); // 本地午夜，月份5 = 六月
// 安全做法：始终明确指定时区
new Date("2026-06-04T00:00:00Z"); // UTC（Z很重要）
new Date("2026-06-04T00:00:00+08:00"); // 北京时间
// 将时间戳转换为可读日期
const ts = 1780646400;
new Date(ts * 1000).toISOString(); // "2026-06-04T12:00:00.000Z"
new Date(ts * 1000).toLocaleString("zh-CN", {
timeZone: "Asia/Shanghai"
}); // "2026/6/4 20:00:00"2038年问题（是真的）
有符号32位整数最大值是2,147,483,647。Unix纪元之后这么多秒对应的时间是2038年1月19日 03:14:07 UTC。过了这个时刻，32位时间戳会溢出为负数，回绕到1901年12月13日。这就是Unix系统的"千年虫"问题，距今只有12年。
受影响的系统：嵌入式系统（IoT设备、车载电脑、工业控制器）、使用32位时间戳列的旧数据库、使用32位time_t的C程序，以及存储32位时间戳的文件格式（ext3文件系统、某些ZIP实现）。Linux内核在5.6版本（2020年）为32位架构切换到了64位time_t，但用旧版库编译的用户空间程序可能仍然使用32位time。
不受影响的系统：所有64位系统（所有现代服务器、桌面系统和手机）、JavaScript（时间戳使用64位浮点数）、Python（任意精度整数）、Java（long是64位）、PostgreSQL（timestamp类型是64位）。如果你在2026年开发Web应用，几乎可以确定不会有问题。风险在于嵌入式系统和那些2038年之前不会被更新的遗留代码。
如果你维护遗留系统：审计你的时间戳存储。MySQL的TIMESTAMP类型在8.0.28（2022年）之前是32位的——旧版本会在2038年溢出。SQLite以文本或64位整数存储时间戳（安全）。检查所有使用time_t的C/C++代码——在32位平台上它可能仍然是32位。修复方法通常是用_TIME_BITS=64重新编译或迁移到64位平台。
数据库中存储时间戳
PostgreSQL：使用TIMESTAMPTZ（带时区的时间戳）。尽管名字如此，它并不存储时区——它存储UTC，并在输入/输出时根据会话时区进行转换。普通的TIMESTAMP（不带时区）存储你给它的任何值，不做任何转换，这会导致歧义。始终使用TIMESTAMPTZ。
MySQL：TIMESTAMP存储UTC（4字节，旧版本范围1970-2038，8.0.28+版本已扩展）。DATETIME存储字面值，不进行时区转换（8字节，范围1000-9999）。对于"这件事什么时候发生的"用TIMESTAMP（自动转换为UTC），对于"安排在这个确切日期/时间，不论时区"的场景用DATETIME（比如生日或特定时区的会议）。
MongoDB：Date类型将毫秒级纪元时间存储为64位整数。内部始终是UTC。ISODate() shell辅助函数只是new Date()的语法糖。将所有日期存储为Date对象，而不是字符串。字符串日期无法高效索引，比较运算符在跨时区时也不会正确工作。
通用建议：存储UTC时间戳，将用户时区单独存储（使用IANA时区字符串如"Asia/Tokyo"），在应用层计算本地显示时间。永远不要存储预格式化的日期字符串——你会失去为不同语言环境重新格式化的能力，也无法在时区规则变更时重新计算（这比你想象的更频繁——各国政府经常调整夏令时规则）。
闰秒（极端边界情况）
地球自转在变慢，因此UTC偶尔会添加"闰秒"以与天文时间保持同步。当这发生时，时间23:59:60会存在一秒钟，然后才进入午夜。Unix时间戳的处理方式是要么重复一秒（时钟显示同一个时间戳两次），要么"涂抹"闰秒到更长的时间段（Google的做法：将其分散到24小时内，使每秒略长一点）。
实际上，闰秒造成过真实的故障。Reddit在2012年6月闰秒期间宕机30分钟，因为Linux内核的时钟处理有个bug导致CPU使用率飙升。Cloudflare在2017年1月闰秒期间出现了短暂故障，因为他们的RRDNS软件在闰秒时计算出了负数时间差。这类bug很少见，但一旦出现就很壮观。
好消息：国际计量局（BIPM）在2022年投票决定在2035年前废除闰秒。在那之前，自1972年以来已经累计了27个闰秒。大多数现代系统使用NTP（网络时间协议）来透明处理闰秒。如果你在构建需要跨闰秒边界保持亚秒级精度的系统（金融交易、科学仪器），请使用TAI（国际原子时），它没有闰秒。
对于大多数开发者：忽略闰秒就好。你使用的语言标准库会处理它们（或者假装它们不存在，对99.99%的应用来说都没问题）。不要尝试手动处理。你唯一会注意到的情况是，当你计算跨闰秒边界的精确时长时得到一"分钟"61秒——技术上这是正确的。
时间戳实用模式
模式一：API响应。返回带时区偏移的ISO 8601字符串："2026-06-04T15:30:00+08:00"，或带Z后缀的UTC格式："2026-06-04T07:30:00Z"。不要在面向用户的API中返回裸Unix时间戳——没有转换器它们不可读。内部服务间API可以使用毫秒时间戳以提高效率。
模式二：调度未来事件。存储预期的本地时间和时区：{time: "2026-12-25T09:00:00", timezone: "America/New_York"}。不要预先转换为UTC，因为如果时区规则变更（政府调整夏令时日期），你存储的UTC时间就会变得不正确。在执行时使用最新的时区数据库转换为UTC。
模式三：审计日志和事件溯源。在单个进程内对事件排序时使用单调时钟（而非挂钟时间）。挂钟可能向后跳跃（NTP校正、虚拟机迁移、闰秒）。对于跨机器排序，使用逻辑时钟（Lamport时间戳、向量时钟）或有限误差的同步时间戳（Google Spanner的TrueTime、AWS Time Sync）。
模式四：年龄计算。不要用时间戳相减再除以每年秒数（365.25 × 86400）。这对闰年、夏令时转换和时区差异都会出错。使用正确的日期库来计算日历差值：date-fns的differenceInYears()、Python的relativedelta，或我们的age-calculator工具——它能正确处理所有这些边界情况。