看懂 Unix 时间戳：别再换算错一天

开发更新于 2026-09-29

时间戳是一个计数，而它只有在知道「从哪里数起」和「以什么为单位」之后才有意义。时间戳转换把一个数字变成它指代的那一刻，给出四种格式，也支持反向转换。数字本身很好填，页面内建的两条假设才是容易翻车的地方。

秒还是毫秒：按长度判定

输入框的提示写着「输入秒（10位）或毫秒（13位）」，实现也正是这条规则——看字符长度：13 位及以上按毫秒，短于 13 位一律按秒。

这条规则之所以大体成立，是因为两种刻度的位数分界刚好落在同一时刻：

也就是说，从 2001 年 9 月 9 日那一刻起，10 位数是秒、13 位数是毫秒，用长度判断对今天所有常规输入都够用。

表里同时暴露了失效区间。11 位和 12 位的值永远按秒处理，于是：

2001 年 9 月之前的毫秒时间戳只有 12 位或更少。100000000000（按毫秒是 1973-03-03）会被乘上一千，落到公元 5138 年。
到了 2286 年 11 月之后，秒会变成 11 位，反而被当成毫秒。

所以换算结果如果远得离谱，先别怀疑工具，先检查你手里那个值是不是「位数不足的毫秒」。自己乘或除一千，再输一次。

同一条长度规则还有两个连带现象：

负号也算一位。 -170000000000 是 13 个字符，按毫秒处理并落在 1970 年之前，符合预期；1970 年之前的时间可以正常转换，-1000000000 秒对应 1938-04-24。
这是一个 number 输入框，接受科学计数法，而 1e12 只有 4 个字符，于是被当作秒、乘一千，报出公元 33658 年的日期。请老老实实输数字，别输简写。

输入合法值后你会看到：

UTC —— HTTP 风格的字符串，以 GMT 结尾，精确到秒。在哪儿读都同一个意思。
本地时间 —— 按你机器的时区渲染，并把时区名和偏移写出来。就是这一行会让两个人读出不同结果，也是「日志明明是 5 号，转换器却说 4 号」的常见来源。
ISO 8601 —— 永远是 UTC，以 Z 结尾，带毫秒。要贴进工单或另一个工具，用这一行。
可读格式 —— 本地时间的松散写法，中文页形如 2026年9月29日 14:05:07 二。注意月份和日期不补零，所以这一行拿去做文本排序会乱。它只适合用眼睛看，不适合当键值。

底层能表达的区间就是 JavaScript 的日期范围：±8,640,000,000,000,000 毫秒，大约公元 ±275760 年。超出这个范围不会报错——原因见下一节。

这是最该记住的一条行为：转换没有错误分支，也没有状态提示。

清空输入框会把四行都重置为 --，这一种是有处理的。
大到无法成为日期的数字——二十位，或者溢出成无穷的科学计数法——输入框接受、内部转换失败，然后让上一次的四个结果原样留在屏幕上，毫无变化。框里是新值，四行还是旧时刻。连续两次溢出的话，看起来就像工具在无视你。

所以请把「结果没动」当成错误信号。若觉得转换卡住了，先清空、确认变成 --，再输入一个你已经核对过位数的值。

反向方向用的是浏览器的日期时间选择器，它有一个必须先知道的限制。

选择器只提供日期、小时和分钟，没有秒。于是从这里读出的数字永远是整分钟：秒值必为 60 的整数倍，毫秒值末尾必是 000。而且页面加载时它会被预置成当前的时分，所以首次打开时显示的那个数最多比真实现在旧 59 秒。

用来估算「明天下午三点大概是多少」没问题；用来复现某条日志就不合适。需要精确到秒，请从第一个标签页入手，或者用页顶的实时时钟。

实时时钟同时给出秒和毫秒，每秒刷新一次，是取「此刻」最快的办法。它没有复制按钮，第一个标签页的四个输出也没有；整页只有这一栏的两个时间戳字段带 Copy。其余地方请手工选中再复制。

时区是显示选择，不是数字的属性。 Unix 时间戳命名的是一个瞬间，1700000000 在上海和柏林是同一刻。不同的只是为它打印出来的日期和钟点。两个人转换同一个值得到不同日期，谁都没错——只是所在时区不同，动的是日期的分界线。请存时间戳、比时间戳，只在最后一步为人类格式化。

Unix 时间不含闰秒。 在这套刻度里每一分钟都恰好 60 秒，包括天文意义上多出一秒的那一分钟。所以时间戳彼此之间是自洽的——求差、排序都没问题——但它不是一把绝对均匀的物理钟。只有在跨闰秒做亚秒级运算时这件事才要紧，而那时候它非常要紧。

不会。转换用的是浏览器里的 Date 对象和选择器自身的取值：没有请求、没有历史记录、没有账号。实时时钟和四种格式都取自你机器的时钟与时区设置——反过来说，这个页面的准确度也受限于你系统时钟本身。