Unix时间戳转换器

如何转换Unix时间戳

1. 把时间戳粘贴到输入框，秒或毫秒都可以。
2. 读取转换后的日期与时间，UTC和本地时区两种结果同时显示。
3. 想反向转换，就在日期字段里填入日期和时间。
4. 复制得到的epoch值，用于你的查询、脚本或API调用。
5. 只想要「现在」时，直接看顶部实时跳动的当前时间戳即可。

这个转换器做的是什么

这个工具在epoch时间和可读日期之间双向转换。粘贴一个Unix时间戳，就能看到它代表的准确瞬间，同时以UTC和你本地时区两种形式呈现；也可以选一个日期和时间，反推回epoch值。当你只需要「现在」时，页面顶部还会实时跳动显示当前时间戳。

一切都在你的浏览器本地即时、私密地完成。秒和毫秒都能处理，而且结果始终是同一个底层瞬间，只是显示在你正在阅读的那个时区里而已。

秒还是毫秒：经典的差1000倍

如果转换出来的日期落在1970年代，说明你的时间戳本是秒，却被当成毫秒解读了；反过来,如果日期跑到几万年后，则是把秒当成了毫秒。有个经验法则：当前的秒级时间戳是10位数，毫秒级是13位。工具会根据长度自动判断并转换，但了解为什么会搞混仍有价值：Unix工具和多数API用秒，而JavaScript和Java用毫秒。

还要记住，时间戳本身没有时区。它是一个全球统一的瞬间，只有当你把它格式化成日期时才会出现时区。这也是为什么同一个epoch，在UTC和你本地时区里会显示成不同的钟表时间。

Unix时间究竟是什么

Unix时间是自1970年1月1日UTC零点起经过的秒数，这个时刻被称为epoch（纪元）。它给每一个瞬间一个唯一无歧义的数字，没有月份名称、没有分隔符、也不必操心地区习惯，这就是为什么系统内部存的是它，而不是格式化的日期字符串。

关键在于，这个数字是一个绝对的UTC瞬间。它本身不携带时区；只有当你把它渲染成可读日期时才会套上一个时区。同一个时间戳对地球上每个人都是同一个瞬间，尽管伦敦、纽约和东京的钟表读数各不相同。

你会在哪里遇到时间戳

epoch值在软件里无处不在：日志文件、JWT的过期（exp）和签发（iat）字段、API请求与响应的载荷、数据库行、缓存头，以及定时任务的排查。当一条日志说某事发生在1757203200，把它转换一下就能知道那是在一次上线之前还是之后——而这通常就是问题的全部。

它们也是在系统之间传递某个瞬间最稳妥的方式。由于时间戳与时区无关，服务器、客户端和数据库可以各自存下同一个数字，再按各自用户偏好的时区去渲染，对所指的究竟是哪个瞬间毫无歧义。

时区与格式化

这个转换器会把每个时间戳同时按UTC和你浏览器的本地时区显示，让你一眼看到时差。如果某个日期看起来「差」了好几个小时，你几乎总是在拿UTC和本地时间作比较，而不是碰上了bug；瞬间是同一个，只是呈现方式不同。

一个实用的习惯是搞清楚你的数据源用的是哪个时区。服务器绝大多数按UTC记录日志，所以在关联事件时就按UTC来读，只有当你要推断某个具体用户在他所在地经历了什么时，才切换到本地时间。

2038年问题与32位限制

把Unix时间存进有符号32位整数的系统，最多只能数到2,147,483,647秒，也就是2038年1月19日UTC 03:14:07。过了这一刻，数值就会溢出并翻转成负数，退回到1901年——相当于纪元时代版的千年虫。

现代的64位系统把这个上限推到了几十亿年之后，本转换器本身也能处理远超2038年的日期，以及1970年之前的负时间戳。实际的教训是：确保任何存储或传输epoch时间的代码都使用64位类型。

常见错误与相关工具

反复出现的错误是：秒与毫秒搞混、忘了裸时间戳没有时区，以及在两种单位之间换算时做了截断而非四舍五入。记住位数法则——在今天的日期下，秒是10位、毫秒是13位——一眼就能抓出其中大多数。

在相关工作上，它与本站其他开发者工具并肩而立，这些工具全都完全在客户端运行。无论你是在解码JWT载荷的exp字段，还是把日志条目和一次发布对齐，这里的转换都是精确的，而且始终留在你的机器上。

常见问题

相关工具