Unix时间戳在线转换工具 — 时间戳转日期

Unix 时间戳记录的是从 1970 年 1 月 1 日 00:00:00 UTC 起经过的秒数——比如时间戳 1,000,000,000 对应 2001 年 9 月 9 日。把 Unix 时间戳转换成可读的日期，或选择日期获取对应的时间戳。工具自动识别秒和毫秒，同时显示本地时间、UTC 和 ISO 8601 格式，顶部还有实时跳动的当前时间戳。

工具介绍

Unix 时间戳（也叫 epoch 时间）是从 1970 年 1 月 1 日 00:00:00 UTC 起经过的秒数。它是计算机存储时间点的标准方式：数据库、日志文件、API 和各种编程语言都在用，因为它是一个不含时区歧义的纯数字。

常见两种精度：秒（现在是 10 位数字，如 1720500000）和毫秒（13 位，JavaScript 和 Java 使用）。本工具会自动识别你粘贴的是哪一种。

为什么使用它？

秒读日志、数据库记录和接口返回里的时间戳。
自动识别秒/毫秒，不用自己判断。
同时显示本地时间、UTC、ISO 8601 和相对时间（"3小时前"）。
双向转换：时间戳 → 日期、日期 → 时间戳。
顶部实时时钟，随时查看当前时间戳。

使用方法

解码：把时间戳（如 1720500000）粘贴到左侧输入框，点"转换"。
查看本地时间、UTC、ISO 8601 和相对时间。
编码：在右侧选择日期时间，点"转换"得到秒和毫秒两种时间戳。
只需要当前时间戳时，直接看顶部的实时时钟。

示例

输入

1720500000

输出

本地时间: 2024/7/9 13:20:00
UTC 时间: Tue, 09 Jul 2024 05:20:00 GMT
ISO 8601: 2024-07-09T05:20:00.000Z

10 位数字按秒处理，13 位按毫秒处理。

实用技巧

排查"时间不对"的 bug：90% 是时区显示问题而不是时间戳错了。改代码之前先拿 UTC 那一行对比服务器日志（服务器通常记 UTC）。
日期正好落在 1970-01-01，说明时间戳是 0 或缺失——经典的空值症状，不是真实日期。
日期在 1970 年附近加几天，通常是秒被当成毫秒处理了；日期跑到公元 56000 年以后，则是反过来。
表格软件注意：Excel 数的是 1900 年起的天数，不是 1970 年起的秒数。秒级时间戳用 =(A1/86400)+DATE(1970,1,1) 转换。

真实使用场景

时间戳实际咬人的地方：读 JWT 和 API 令牌里的过期字段（exp/iat 都是 Unix 秒）、把用户报障时间对到服务器日志行、设置缓存 TTL 和定时任务窗口、确认证书或令牌到底过没过期。相对时间那一行（"3小时前"）是所有这些场景最快的合理性检查。

JWT 调试值得单独说：先用 Base64 工具解出令牌的 payload，再把 exp 值贴到这里——"令牌过期没有、过了多久"立刻有答案。

Unix时间为什么这么设计

从一个固定起点开始存一个不断递增的数字（而不是年/月/日/时的结构），是刻意追求简单的设计取舍：两个时间戳可以直接用普通算术比较或相减，不需要任何日历逻辑，这正是数据库、日志格式、以及几乎所有编程语言内部的日期表示都基于它的原因。这份简单的代价，正是本工具存在要解决的问题——人类不会按"1970年以来的秒数"思考时间，所以任何时间戳要对人有意义都得先翻译回日历日期，而这个翻译同时要处理时区、精度（秒还是毫秒）和显示格式三件事。

→ Base64 编码解码 · 年龄计算器

常见问题

工具怎么知道我输入的是秒还是毫秒？

看数值大小。大于等于 1e12（1,000,000,000,000）按毫秒处理，小于按秒处理。当前日期的秒级时间戳约 17 亿，毫秒级约 1.7 万亿，两个范围不会重叠。

为什么转换出来的小时和我预期的不一样？

时区问题。时间戳本身永远基于 UTC，"本地时间"一行是按你设备的时区转换的。很多服务器日志用的是 UTC，对比 UTC 那一行即可。

什么是 2038 年问题？

用有符号 32 位整数存时间戳的系统会在 2038 年 1 月 19 日溢出。现代系统都用 64 位整数，不受影响。本工具使用 JavaScript 数字类型，可以处理远超 2038 年的日期。

可以转换负数时间戳吗？

可以。负时间戳表示 1970 年 1 月 1 日之前的日期，例如 -86400 是 1969 年 12 月 31 日。

时间戳包含闰秒吗？

不包含。Unix 时间假设每天恰好 86400 秒，忽略闰秒——这是有意的简化，让时间计算保持简单。

Unix 时间戳在线转换

时间戳 → 日期

日期 → 时间戳