时间戳转换

Unix 时间戳在转换之前就是一串看不出任何信息的整数。这个工具把时间戳翻译成人类可读的日期，也能反过来转换，并把 ISO 8601、UTC 和你的本地时间并排展示。它适合阅读服务器日志、检查 API 载荷和查看数据库记录。

两个方向如何工作

时间戳转日期方向，对秒乘以 1000，对毫秒则原样使用，然后把得到的瞬间渲染成三种形式。日期转时间戳方向则相反：它从选择器读取一个日历日期和可选的时间，在你的浏览器本地时区里解释它们，并同时以秒和毫秒报告 epoch 值。秒的结果是向下取整的，所以带小数秒的时间会被朝过去的方向截断。

还有一个实时面板同时以两种单位显示当前瞬间，每秒刷新一次，让你不用打开控制台就能复制「现在」。

实操转换

输入	单位	UTC 输出
0	秒	1970-01-01T00:00:00.000Z
1700000000	秒	2023-11-14T22:13:20.000Z
1754478800	秒	2025-08-06T11:13:20.000Z
1754478800000	毫秒	2025-08-06T11:13:20.000Z
2147483647	秒	2038-01-19T03:14:07.000Z

反方向转换时，1970-01-01T00:00:00Z 对应 0 秒，2024-01-01T00:00:00Z 对应 1704067200 秒。这些反向示例是以 UTC 给出的；通过日期选择器输入时，它们反映的是浏览器的本地偏移，所以同一个日历日期可能给出相差一个时区偏移量的数值。

秒与毫秒：如何区分

在 2025 年，以秒为单位的时间戳有 10 位，约 17 亿。毫秒时间戳有 13 位，约 1.75 万亿，因为 JavaScript 的 Date.now() 计的是毫秒。有些系统还会更细：微秒是 16 位，纳秒是 19 位。粘贴一个值后，先数位数再选单位。在单位选择为秒时传入 13 位的毫秒值，会得到远在未来的日期；而把 10 位的秒值当作毫秒传入，则落在 1970 年 1 月。

工具不会自动识别单位，必须由你选择。自动识别只能靠猜，而猜错比显式选择更难被察觉。

时区与本地时间的陷阱

时间戳记录的是一个瞬间，而不是表盘读数，所以数字本身与时区无关。只有渲染出的输出会随地点改变。ISO 输出始终以 Z 结尾，因此在任何地方都稳定。本地输出使用浏览器的区域设置和偏移，包含该瞬间是否处于夏令时，这正是把一行日志与自己的钟表对应起来时想要的。

反方向才是陷阱。输入不带偏移的日期和时间，意味着「我这里的这个表盘时间」。如果你想要的是 UTC，请直接输入时间戳，或者用一个已知的 UTC 参照去换算目标 UTC 日期。这是在不同机器之间复制数值时最常见的偏差数小时的 bug 来源。

2038 年问题

许多老系统用有符号 32 位整数存时间戳，其最大值是 2,147,483,647 秒，即 2038-01-19T03:14:07Z。再过一秒，数值回绕成负数，被解释为 1901 年 12 月。现代的 64 位平台在任何现实时间范围内都不受影响。如果你维护遗留数据库或嵌入式系统，这就是需要提前规划的那个日期。

在日志与 API 中读取时间戳

服务器日志常常在方括号里打印 epoch 秒，例如 [1754478800] GET /api/v1/users。把数字粘进来、单位选秒，ISO 输出就给出精确的瞬间。API 错误载荷有时携带的是毫秒，从 13 位长度就能认出来；切换单位就能修正本来错误的日期。

JWT 是另一个常见来源。iat、nbf 和 exp 声明都是从 epoch 起的秒数。解码一个令牌会得到这些数字，而本工具能把 exp 声明变成可与实时当前时间面板对照的过期日期。一个一小时前就过期的令牌，只要把数字变成日期就一目了然。

数据库记录是第三种情况。许多引擎存秒，而基于 JavaScript 的服务存毫秒，所以选择单位前请先确认列定义或 ORM。当两个系统对同一个时间戳不一致时，直接比较 epoch 整数，而不是渲染出来的本地字符串。

常见错误

搞混秒和毫秒是最常见的错误。其次是忽视日期选择器的本地时间解释而误以为它是 UTC。第三是通过肉眼看跨时区的时间戳：要比的是 epoch 数字，而不是渲染出的本地字符串。最后要记住，epoch 时间忽略闰秒，所以对时间戳做算术并不是物理经过时间的完美度量。

更隐蔽的一个错误，是以为时间戳自带时区。它没有：1700000000 在任何地方都是同一个瞬间，只有它的显示会变。存储本地表盘时间字符串而不是 epoch，会丢掉偏移，并在有夏令时的地区每年有两次变得有歧义。拿不准时，存 epoch，读取时再渲染。

相关工具

• Cron 生成器
• Cron 下次运行
• JWT 解码器
• 日期计算器
• 世界时钟