跳到正文
DevTools / Unix 时间戳转换

Unix 时间戳转换

Unix 时间戳没有歧义却不可读,对机器是优点,对凌晨两点看日志的人是缺点。本转换器支持双向换算,接受秒、毫秒、微秒或纳秒并自动判断单位,以 ISO 8601、RFC 2822 和人类相对时间等十四种格式输出,可在浏览器已知的四百多个时区中任选,还能在需要盯着时钟时从当前时间实时走动。

完全在浏览器本地运行——不会上传任何内容。

当前 Unix 时间
—
毫秒时间戳—
本地时间—

支持时间戳或日期字符串

工作原理

Unix 时间戳统计的是自 1970 年 1 月 1 日 00:00:00 UTC 起经过的时间,且不含闰秒——这意味着它严格来说不是经过秒数的计数,这一点只对天文学家和需要与单调时钟比较的人有影响。它在构造上就没有时区,这正是它的价值:同一时间戳在任何地方都表示同一瞬间,只有在渲染时才套用时区。围绕时间戳的困惑大多来自忘记这个数字根本不携带时区信息。

单位是缺陷最常见的来源。Unix 时间惯例用秒,而 JavaScript 的 Date 构造函数和多数移动平台用毫秒,于是把 1700000000 当作毫秒解释会落到 1970 年 1 月,把 1700000000000 当作秒解释会落到几万年之后。两种错误在这里都一眼可见,输入单位会根据数值大小自动判断——十位数是秒,十三位数是毫秒——并可在两个方向上手动覆盖。

2038 年问题是另一个值得知道的边界。32 位有符号整数表示的秒会在 2038 年 1 月 19 日溢出,任何以这种方式存储时间戳的系统——包括许多嵌入式设备、较旧的数据库,以及 32 位平台上使用 time_t 的 C 代码——都会回绕成负值并报出 1901 年的日期。解决办法是改用 64 位整数,新代码中这已是通例,但在现网系统中远非普遍。本工具全程使用 64 位运算,因此 2038 年之后的日期也能正确渲染。

渲染才是时区介入的环节。同一瞬间在冬季的伦敦是 09:00,在夏季则是 10:00,而这个偏移量并不是常数——它取决于各国政府随时可能调整的夏令时规则。转换器使用浏览器自带的时区数据库,也就是让你的操作系统时钟保持正确的那份数据,因此它反映的是历史与已公布的规则变更,而不是硬编码的偏移表。Europe/London、America/New_York 这类 IANA 时区名才是正确的标识符;EST、CST 之类的缩写含义模糊,任何存储或交换时间的系统都不应使用。

常见应用场景

  • 把数据库行或日志行里的时间戳读成真实日期。
  • 为查询区间或缓存过期请求头生成时间戳。
  • 检查接口的 exp 或 iat 字段是否指向过去的时间。
  • 按同事所在时区确认事件发生的当地时间,而不是只看自己的。
  • 在迁移前确认某个系统存的是秒还是毫秒。
  • 把日期转换成 ISO 8601 字符串,用于日志格式或 JSON 字段。

最后更新: 2026-10-14

常见问题解答

时间戳应该存秒还是毫秒?

无论选哪个都要明确表达,而不是默认其一。秒是 Unix 惯例,也是多数数据库和接口使用的单位;毫秒是 JavaScript 和许多移动端 SDK 使用的单位。失败模式是相差一千倍的静默误读,它产生的不是一个报错,而是一个看似合理却落在错误年代的日期。无论选哪个,都把单位写进列名或接口字段名——created_at_ms 是自解释的,created_at 不是。

什么是 2038 年问题?

用 32 位有符号整数保存自 1970 年起的秒数,会在 2038 年 1 月 19 日 03:14:07 UTC 溢出成最小负值,日期变成 1901 年 12 月 13 日。任何使用 32 位 time_t 的系统——较旧的 C 代码、部分嵌入式固件、一些遗留数据库 schema——都会受影响。解决方案是用 64 位整数存储时间戳,这在新代码中是标准做法,但对于长期运行的系统仍值得审计,物联网设备尤其如此。

为什么同一个时间戳在我和同事那里显示不同时间?

因为时间戳表示的是一个瞬间,时区是在渲染时套用的。如果同事位于另一个时区,他们的浏览器会用当地偏移量渲染同一瞬间;当一方实行夏令时而另一方没有时,这个差异会在几周内变化一小时。这是正确行为:存储和传输瞬间,只在显示时转换为本地时间。本工具允许显式选择任意时区,使目标时区不再有歧义。

Unix 时间会计算闰秒吗?

不会。Unix 时间是经过秒数的计数,但不含闰秒,因此它比严格的 SI 秒计数少了自 1972 年以来插入的 27 个闰秒。实际后果是 Unix 时间与 UTC 之间存在一个小整数差,如果某个系统拿它与原子钟而非日历比较,就会因这个差值而出错。除了精密天文和卫星导航之外,正是这一简化让该格式变得实用。

相关工具