Unix 时间戳转换器
将 Unix 时间戳（epoch）转换为可读的日期和时间。
Unix 时间戳转换：秒还是毫秒
粘贴时间戳后，工具会去掉首尾空格，按长度判断单位：11 个字符以内按秒，12 个字符及以上按毫秒。所以 Linux 命令行或数据库里常见的 10 位秒级时间戳，和 JavaScript 的 Date.now()、Java 日志里的 13 位毫秒级时间戳，都能转换成正确的日期：
| 输入 | 按什么读 | UTC 结果 | 北京时间 |
|---|---|---|---|
1792368000 | 秒 | Mon, 19 Oct 2026 00:00:00 GMT | 2026/10/19 08:00:00 |
1792368000000 | 毫秒 | Mon, 19 Oct 2026 00:00:00 GMT | 2026/10/19 08:00:00 |
判断依据是字符个数，不是数值大小。99999999999（11 位）按秒读，得到公元 5138 年的日期；100000000000（12 位）按毫秒读，得到 1973 年 3 月 3 日。
UTC 部分和本地时间部分
结果用“/ 本地时间：”隔开，显示同一时刻的两种写法。前面是固定格式的 UTC 时间，后面按你浏览器的时区和语言显示，所以不同的人看同一个时间戳，本地部分可能不一样。
以 1792411200 为例，UTC 部分是 Mon, 19 Oct 2026 12:00:00 GMT。时区为北京时间（UTC+8）的中文浏览器，本地部分显示 2026/10/19 20:00:00，比 UTC 早 8 小时。对比不同地区服务器的日志，或者在问题报告里贴时间时，请用 UTC 部分。
格式不对时会得到错误日期或“—”
单位只看长度，所以下面几种格式会出错：
| 输入 | 看到的结果 | 改法 |
|---|---|---|
1792368000.5 | 1970 年 1 月 21 日：共 12 个字符，被当成毫秒 | 去掉小数部分 |
1792368000123456（微秒） | 公元 58767 年的日期 | 删掉最后 3 位 |
| 19 位的纳秒时间戳 | — | 删掉最后 6 位 |
1,792,368,000 | — | 去掉逗号 |
17923680（少了几位） | 1970 年 7 月 27 日 | 检查是否复制完整 |
科学计数法如 1.79e9 可以识别，按秒处理。负数也可以，得到 1970 年以前的日期；很长的负数会因为负号多占一个字符而被当成毫秒。
当前时间戳，以及日期转时间戳
页面顶部的“当前 Unix 时间戳”是页面加载那一刻的秒数，不会自动跳动，想要新的数值就刷新页面。这个数字带千位分隔符，方便阅读；粘贴到代码里或输入框里之前先去掉逗号，否则会显示“—”。
本页只能把时间戳转成日期。要把日期转成时间戳，可以打开浏览器的开发者工具控制台，运行 Math.floor(Date.parse("2026-10-19T00:00:00+08:00") / 1000)，得到北京时间零点的 1792339200。把 +08:00 换成 Z 表示 UTC 零点，得到 1792368000。两种都不写时，日期会按你电脑的本地时区解读。
常见问题
为什么数据库里的时间和实际差了 8 小时？+
时间戳本身多半是对的，问题出在存或读的环节：把北京时间当作 UTC 存了进去，或者反过来。把时间戳粘贴进来，对照 UTC 部分和本地时间部分，就能看出差的这 8 小时出在哪一边。
JWT 里的 exp 和 iat 能转换吗？+
可以。这两个字段都是秒级时间戳，把解码后载荷里的数字直接粘贴进来，就能看到对应的日期。
2038 年问题是什么？+
用有符号 32 位整数保存的秒级时间戳，最大只能到 2,147,483,647，也就是 UTC 2038 年 1 月 19 日 03:14:07（北京时间同日 11:14:07），再往后就会溢出。解决办法是改用 64 位的时间类型。
输入的时间戳会上传吗？+
不会。转换用的是浏览器自带的日期函数，边输入边计算，不上传任何内容。