设备与系统问题
Unix Timestamp 的秒与毫秒:日期为什么会变成 1970
把 Unix timestamp 转成日期却得到 1970 年附近,往往是把秒当成了毫秒。如何区分单位并正确转换。
如果 Unix timestamp 转成日期落在 1970 年附近,多半是单位搞错了。
Unix timestamp 通常用秒,JavaScript 的 Date 通常用毫秒。
现在的日期里,10 位常常是秒,13 位常常是毫秒。单位对不上时,可能需要乘以或除以 1000。
你把 timestamp 转成日期,结果是 1970 年 1 月。很少是时钟坏了。数字是按毫秒读的,实际却按秒存着——或者反过来。
什么是 Unix timestamp?
Unix timestamp 表示从 Unix epoch(1970-01-01 00:00:00 UTC)起经过的时间。通常用整秒。同一时刻也可以存成毫秒(秒 × 1000)。数字本身不标明单位。
秒与毫秒:相差 1000 倍
1 秒等于 1000 毫秒。比较 1720000000 和 1720000000000。前者是秒、后者是毫秒时,它们是同一瞬间。把前者当毫秒读,日期就会跳向 1970。
下面的 UTC 结果由上面的数字算出,不是猜测。
| 数值 | 常见单位 | 含义(UTC) |
|---|---|---|
| 1720000000 | 秒 | 按秒解读为近期日期:2024-07-03 09:46:40 UTC |
| 1720000000000 | 毫秒 | 按毫秒解读为同一瞬间:2024-07-03 09:46:40 UTC |
| 把 1720000000 当毫秒 | 单位错误 | 接近 1970:1970-01-20 21:46:40 UTC |
为什么会显示 1970?
把秒值当成毫秒处理,数字会小 1000 倍。JavaScript 只从 Unix epoch 起算了一小段,日期就停在 1970:
const seconds = 1720000000;
new Date(seconds);
// 1970-01-20 21:46:40 UTC
new Date(seconds * 1000);
// 2024-07-03 09:46:40 UTC
这个 1970 日期是 epoch 再加大约两周。传给 Date 之前,先把秒乘以 1000。
- 秒 (SECONDS)
- 1720000000
- 毫秒 (MILLISECONDS)
- 1720000000000
- 秒值
- 被误当成毫秒
- 接近 1970 的日期
如果结果接近 1970,先查 timestamp 单位,再去查时区。
10 位一定是秒、13 位一定是毫秒吗?
对现在的日期,10 位常常是秒,13 位常常是毫秒。这是快捷线索,不是校验规则。位数会随时间范围变化,有的 API 存微秒或纳秒。要用文档或说得通的日期来确认单位。
为什么 JavaScript 里特别常见
JavaScript 里数字 Date 是 epoch 起的毫秒。很多后端、数据库和 Unix 工具仍存秒。把秒直接传给 Date 是常见错误:
const unixSeconds = 1720000000;
const wrong = new Date(unixSeconds);
const correct = new Date(unixSeconds * 1000);
wrong 落在 1970 附近(1970-01-20 21:46:40 UTC)。correct 才是目标的近期时刻(2024-07-03 09:46:40 UTC)。
其他系统可能用不同单位
其他语言、API 和数据库可能用秒或毫秒。有的存微秒或纳秒。不要假定某种语言永远只用一种单位——看文档。如果数字在 JSON 里,JSON 格式化、校验与对比 能让字段更好读,但仍然不会告诉你单位。
怎么判断 timestamp 用的是哪种单位?
按这个顺序检查。只看位数不够。
- 查 API 或数据库文档。
- 看大概有多少位。
- 和合理的近期 timestamp 比大小。
- 分别按秒和按毫秒试一次。
- 看得到的日期是否说得通。
一种解读是 1970,另一种是你认识的日期,原因就是单位不一致。
Unix timestamp 常见错误
- 把秒当成毫秒。 日期会收成 1970,就像上面的例子。
- 把毫秒当成秒。 日期跳到遥远未来,或转换失败。
- 乘以 1000 两次。 本来已是毫秒的值会变得巨大,日期前进几个世纪。
- 除以 1000 两次。 秒值再次缩小,又回到 1970 附近。
- 怪时区。 时区可以改钟点或日历日。它不会把近期 timestamp 变成 1970。
- 把格式化日期字符串当成 Unix timestamp。 像 2024-07-03T09:46:40Z 这样的值不是 epoch 数字。按日期字符串解析,不要当秒。
时区会造成 1970 问题吗?
通常不会。时区会改显示的钟点,临近午夜时也可能改日历日期。它不会把现代 Unix timestamp 变成 1970。结果是 1970 时,先查秒和毫秒。
转换并核对 Unix timestamp
NEXNARA 日期与时间转换器 可在浏览器里转换 Unix timestamp。
可粘贴 Unix 秒或毫秒、使用当前 timestamp、查看 UTC 与本地时间、转换时区并格式化日期。自动检测常常把 10 位当秒、13 位当毫秒;你仍可自己选单位。
转换本身在浏览器中完成。本工具不会把日期或 timestamp 发到 NEXNARA 服务器。广告和其他站点功能仍会用网络;那与转换无关。
要核对 Unix timestamp?打开 日期与时间转换器,比较秒和毫秒。
FAQ
为什么我的 Unix timestamp 显示 1970?
常常是把秒当成毫秒读了。JavaScript 会处理小得多的数字,日期就落在 1970-01-01 00:00:00 UTC 之后不久。把秒乘以 1000 再转一次。
Unix timestamp 是秒还是毫秒?
通常是秒。很多 Web API 和 JavaScript Date 用毫秒。看该系统的文档。有的系统用微秒或纳秒。
秒怎么转成毫秒?
乘以 1000。1720000000 秒等于 1720000000000 毫秒。反过来就除以 1000。
为什么 JavaScript Date 用毫秒?
JavaScript 的数字 Date timestamp 定义为自 Unix epoch 起的毫秒。所以当 unixSeconds 是 Unix 秒时,new Date(unixSeconds) 是错的。
10 位 timestamp 一定是秒吗?
不是。对现在的日期常常是,13 位常常是毫秒。位数是线索,不是规则。用文档或说得通的日期确认。
Unix timestamp 里有时区吗?
没有。Unix timestamp 是从 1970-01-01 00:00:00 UTC 起算的一个瞬间。时区只影响怎么显示,不影响这个数字本身。