Unix 时间戳转换器
将 Unix 时间戳(秒或毫秒)转换为可读日期,并支持反向转换。根据数值大小自动识别单位。
时间戳 → 日期
日期 → 时间戳
- 把 Unix 时间戳粘到上方输入框,或点击「使用当前时间」。
- 保持单位为「自动识别」,如数值有歧义可手动选择秒或毫秒。
- 查看下方显示的 UTC、本地时间和相对时间。
- 若想反向转换,在下方日期选择器中选一个日期,再点击「转换为时间戳」。
它能做什么?
Unix 时间戳是自 1970-01-01 00:00:00 UTC 以来经过的秒(或毫秒)数 —— Linux、macOS、数据库、日志文件和 HTTP 头使用的都是同一纪元。此工具在这个数字和可读日期之间双向转换,同时显示 UTC 与本地时区。它会根据位数自动识别秒或毫秒。
示例
输入(秒,10 位):
1709251200 输出:
UTC (ISO 8601) 2024-03-01T00:00:00.000Z
Local time 3/1/2024, 9:00:00 AM (in a UTC+9 locale)
Relative 2 months ago (relative to now)
Seconds 1709251200
Milliseconds 1709251200000 用毫秒表示的同一时刻是 1709251200000 —— 13 位。
为什么我的时间戳显示了错误的年份?
- 秒与毫秒混淆。
1709251200当作毫秒是 1970 年 1 月;1709251200000当作秒是公元 56137 年。数一下位数 —— 10 位是秒,13 位是毫秒。 - 微秒或纳秒。 有些系统(Python 的 time.time_ns()、Prometheus)输出 16 位或 19 位数值。粘贴前先除以 1000 或 1,000,000。
- 时区混淆。 本地时间行与 UTC 相差你浏览器的时区偏移。如果日志写 12:00:00,网页显示 21:00:00,那是 UTC+9,不是 bug。
- 32 位溢出 (Y2038)。 把时间存成带符号 int32 的遗留系统会在 2147483647(2038 年 1 月 19 日 UTC)回绕为负值,被解释为 1901 年。
- 前导零被去掉。 0012345 会变成 12345。请原样粘贴,不要重新格式化。
- 浮点时间戳。 1709251200.123 表示带小数的秒。工具接受该值,并把小数部分作为毫秒保留。
常见问题
我的时间戳是秒还是毫秒?
数一下位数。大约 2001 到 2286 年之间的时间戳,秒是 10 位(如 1709251200),毫秒是 13 位(如 1709251200000)。看到一个很大的数字且末尾是三个零,几乎可以断定是毫秒。此工具会按数量级自动识别:大于等于 10^12 的值按毫秒处理。
Y2038 问题是什么?
以带符号 32 位整型存储的 Unix 时间戳会在 2038 年 1 月 19 日 03:14:07 UTC(值 2147483647)溢出。仍使用 int32 存时间的系统(旧 C 代码、部分嵌入式设备、某些数据库)会回绕到负数,并被解释为 1901 年 12 月 13 日。现代 64 位系统和 JavaScript 数字不受影响。
为什么时间戳显示了错误的年份?
几乎都是单位不匹配。若你粘贴 1709251200000 而工具按秒处理,会得到约 56137 年的日期;若粘贴 1709251200 而工具按毫秒处理,会得到 1970 年 1 月 20 日。请显式设置「单位」下拉或核对位数。
时间戳是否包含时区?
不包含。Unix 时间戳是自 1970-01-01 00:00:00 UTC 以来的绝对秒数,不携带时区信息。此工具会同时显示 UTC 表示和浏览器的本地时间解释。与同事相差 9 小时属于时区差异,不是 bug。
可以用负值表示 1970 年之前的日期吗?
可以。支持负值 —— 例如 -86400 是 1969 年 12 月 31 日 UTC。并非所有系统都接受(部分数据库和旧语言会夹到 0),但 JavaScript Date 原生支持,此工具能正确转换。
时间戳输入框是否支持 ISO 8601 日期字符串?
不支持,时间戳输入框仅接受数字形式的 epoch 值。请使用「日期 → 时间戳」部分选择日历日期和时间。如有 2024-03-01T00:00:00Z 这样的 ISO 8601 字符串,可在浏览器控制台用 new Date("...").getTime() 获取毫秒,或粘贴到日期选择器里。
你们会保存我转换的时间戳或日期吗?
不会。我们不保留你在此输入的任何时间戳或日期。只要关闭或刷新标签页,一切都会清空 —— 没有日志,我们这边也没有关于你查询内容的记录。你可以在浏览器开发者工具中核实。