理解 Unix 时间戳及如何换算
为什么 epoch 重要、秒与毫秒的陷阱总让工程师中招，以及如何把任意时间戳换算成任意时区的可读日期。
为什么这个工具重要
一名负责日志的工程师在排查告警：日志里写着「1735689600」。这是 2025-01-01 00:00:00 UTC（秒）还是把毫秒误当秒读成了 1970-01-21 02:08:09？选错单位，事后复盘的时间线会差出 55 年。Unix 时间戳便于存储和运算，但对人类极不友好；秒与毫秒的约定又因语言、数据库和 API 而异。可靠的换算器能把单位选择说清楚。
三个真实场景
粘贴 1735689600，换算器显示 2025-01-01 00:00:00 UTC 和 2024-12-31 16:00:00 PST。按受影响用户所在时区选一个，继续排查。
事故分诊更快
在 JST 下输入本地日期时间，复制得到的 epoch（秒或毫秒，取决于你的调度器）。
代码里写入正确的 epoch
粘贴一串 epoch，旁边看到解码后的 UTC 日期，再把结果拷回表格。
报表可读
操作演练
打开 Unix 时间戳换算器。
粘贴时间戳或选择日期
换算器会自动判断是秒（约 10 位，范围约 1973–2286）还是毫秒（13 位）。若数值特殊，可用下拉手动覆盖。
在多个时区查看解码结果
UTC、浏览器本地时区，以及任意自定义 IANA 时区（如
Asia/Tokyo、America/Sao_Paulo）。反向换算
在任意时区输入日期时间；换算器同时输出秒和毫秒的 epoch。
按目标格式复制
1735689600、1735689600000、ISO2025-01-01T00:00:00Z、RFC 2822 — 按接收方支持的格式选用。
输入
1735689600 (seconds)解码结果
UTC: 2025-01-01 00:00:00
ISO: 2025-01-01T00:00:00.000Z
Local: 2024-12-31 19:00:00 (UTC-5)输入
1735689600 (mistakenly read as milliseconds)误当毫秒解码
UTC: 1970-01-21 02:08:09.600
实用技巧
- API 约定里务必写清单位。「给我 Unix 时间戳」容易歧义；「给我以毫秒为单位的整型 Unix 时间戳」则不会。
- 负时间戳对 1970-01-01 之前的日期同样有效 — 换算器支持并会显示正确的公历日期。
- 面向人类展示优先用 ISO-8601。
2026-04-22T15:30:00Z无歧义，且可按字典序排序。 - 批量换算时可每行粘贴一个时间戳。
常见陷阱
常见误区
换时区后的夏令时意外
十月太平洋 09:00 的会议 ≠ 十一月太平洋 09:00，因为 PDT 会切到 PST。请用 IANA 时区（America/Los_Angeles），不要用固定偏移（UTC-8），换算器会处理夏令时。
常见误区
JavaScript Date.getTime() 与 Python time.time()
JS 返回毫秒；Python 返回带小数的秒。移植代码时请显式乘或除以 1000。换算器同时接受两种格式，便于发现不一致。
常见误区
2038 年问题
部分老系统把 Unix 时间存在有符号 32 位整型里。超过 2147483647（2038-01-19）会溢出。若你维护此类系统，应规划迁移到 64 位时间。
不适合用本工具的情况
- 工作日历运算（例如「从现在起 5 个工作日」）。请用
date-fns-business-days一类库或你们财务系统的节假日历。 - 调试 cron 更适合用能输出接下来 N 次触发的 cron 表达式工具。
- 按日历重复的复杂事件（RRULE） 应在 iCalendar 解析器里处理，而不是扁平的秒级换算。
常见问题
「纪元零点」在哪个时区？
0 表示 1970-01-01 00:00:00 UTC。Unix epoch 的定义里隐含 UTC。
为什么每年有两次时间会跳一小时？
那是夏令时。IANA 时区库记录各地区的 DST 规则，换算器会自动应用。
我的输入会上传服务器吗？
不会。换算在浏览器内用内置的 Date 与 Intl.DateTimeFormat 完成；数据不离开页面。
延伸阅读
- 用 时区对比工具 画出跨团队的会议窗口。
- 在 /time-tools/world-clock 添加常用城市的个人世界时钟。
- 用 今日假日工具 查看相关地区当天的公共假日。