10 位和 13 位时间戳有什么区别：秒、毫秒与自动识别

位数差三位，含义差一千倍：10 位是秒，13 位是毫秒。同一个时刻，秒级是 1762300000，毫秒级是 1762300000000。混用不会报错，只会把时间算到 1970 年或几万年以后——这是时间戳相关 bug 里最常见的一类。

为什么会有两种精度

Unix 时间戳的原始定义是「从 1970-01-01 00:00:00 UTC 起经过的秒数」，这也是 C 语言 time_t 的定义。后来前端、Java、JavaScript 的 Date.now() 都用毫秒，于是同一个概念出现了两种精度。

各语言的默认值不一样：PHP 的 time() 给秒，JavaScript 的 Date.now() 给毫秒，Go 的 Unix() 给秒而 UnixMilli() 给毫秒，Python 的 time.time() 给浮点秒。跨语言对接时对不上，多半就是这里。

一眼分辨的办法

看位数最快：

• 10 位（如 1762300000）：秒级。按秒增长，2026 年前后都是 10 位，一直到 2286 年才会进位到 11 位。
• 13 位（如 1762300000000）：毫秒级。按毫秒增长，现在都是 13 位。
• 16 位：微秒级，少数监控与日志系统在用。
• 19 位：纳秒级，常见于 Go 的 UnixNano() 与部分数据库。

位数判断的例外是 1970 年前后的时间（负数或很小），以及某些系统把秒级时间戳当字符串存、前面补了零。

自动识别靠数值范围，不靠位数

按「位数」判断在边界上会出错，可靠的做法是按数值范围：秒级时间戳现在在 10 亿量级，毫秒级在 1 万亿量级，两者相差三个数量级，用阈值一刀切不会误判。

这个工具就是按范围自动识别单位的，同时也允许手动指定秒或毫秒——当你的数据是几十年前的、或者来自测试用例里的边界值时，自动识别可能猜错，手动指定才准。

混用会怎样

把秒当毫秒：时间落在 1970-01-19 附近，看起来像「1970 年」。把毫秒当秒：时间跑到几万年以后，日期格式化后是 +056000-xx-xx 这种奇怪结果。

两种都不会抛异常，只会安静地给出错误时间——所以时间戳相关的问题，第一步永远是确认单位。