Unix 时间戳转换：10 位、13 位与秒/毫秒判定

什么时候真的需要

日志里只有一串数字，需要立刻看出它对应本地时间和 UTC。排查跨时区问题时，两个时间并排看比心算快。

给数据库或 API 写入时间前，把「2026-10-25 15:30:00」换算成 Unix 秒，并确认没有时区偏移。很多接口要秒，另一些要毫秒，差 1000 倍就会错到离谱。

核对第三方返回的 expires_at、iat 这类字段：先确认它是秒还是毫秒，再看它对应的真实时间是否合理。

• 日志时间戳还原
• 写库前本地时间转秒
• 核对 API 的过期时间
• 对比本地时间与 UTC

怎么做才不出错

判断位数：10 位是秒，13 位是毫秒，两者相差 1000 倍。本工具按绝对值是否达到 10^11 判断，小于按秒，大于等于按毫秒，所以 12–13 位按毫秒、11 位仍按秒；带小数的输入一律按毫秒处理。拿不准时先点「当前时间」对照位数。

在 JavaScript 里换算：Date 的构造函数接受毫秒，所以秒要乘 1000，new Date(sec * 1000)；反过来取秒要 Math.floor(Date.now() / 1000)。直接把 Date.now() 当秒用，会得到一个约 1000 倍大的值。

时区：「本地时间」用浏览器的本地时区渲染，夏令时由浏览器按该时区规则处理；UTC 和 ISO 两行固定用 UTC，ISO 输出形如 2026-10-25T07:30:00.000Z。页面没有手动切换时区的选项，所以同一时间戳在不同电脑上看到的本地时间可能不同，UTC 不会变。

不要把 0 当成「没有值」。0 对应 1970-01-01T00:00:00Z，是一个合法时间；表示缺失请用 null，并在读取时单独判断。

2038 年问题来自用 32 位有符号整数存 Unix 秒，最大值 2,147,483,647 对应 2038-01-19T03:14:07Z。本工具用 JavaScript 的 Number 和 Date（双精度浮点），不受这个限制，Date 的上限约为 ±8.64e15 毫秒；但你的数据库字段或服务端如果仍是 32 位，写入前要单独确认。

• 10 位秒、13 位毫秒，差 1000 倍
• JavaScript 里秒要乘 1000
• 本地时间随系统时区，UTC 固定
• 0 是合法时间，缺失用 null

替代方案与局限

命令行：date -u -r 1761328800（macOS）或 date -u -d @1761328800（Linux）直接看 UTC；date -u +%s 取当前秒。适合脚本里批量转换。

代码里用带时区的 API：Python 的 datetime.fromtimestamp(ts, tz=timezone.utc)，Java 的 Instant.ofEpochSecond，Go 的 time.Unix。它们能正确处理时区和格式化。

要同时看纽约、伦敦、东京的墙上时间，或要解析带偏移的 ISO 字符串（如 2026-10-25T15:30:00+08:00），用带时区选择的工具或日期库；本工具只接受纯数字时间戳和本地 datetime 输入，也没有日期加减。

• 脚本批量 → date
• 代码 → 带时区 API
• 多时区、带偏移 ISO → 专门工具
• 本工具不解析偏移、不能切时区