时间戳转换工具
Unix 时间戳与日期时间格式互相转换
时间戳转日期
日期转时间戳
全球时区对比
常用格式示例
什么是时间戳？
时间戳（Timestamp）是表示特定时间的数字值。Unix 时间戳是从 1970年1月1日00:00:00 UTC（称为 Unix 纪元）到指定时间所经过的秒数。它是计算机系统中表示时间的标准方式，具有跨平台、跨时区一致的特点。时间戳分为秒级（10位数字）和毫秒级（13位数字），秒级时间戳常用于 Unix/Linux 系统，毫秒级常用于 JavaScript 等编程语言。
使用说明
时间戳转日期
- 在左侧卡片中输入 Unix 时间戳
- 选择目标时区（如北京时间 UTC+8）
- 点击「转换」按钮查看转换后的日期时间
- 结果包含标准格式、ISO 8601、中文格式等多种形式
日期转时间戳
- 在右侧卡片中选择日期和时间
- 选择该日期时间对应的源时区
- 点击「转换」按钮获取 Unix 时间戳
- 结果同时提供秒级和毫秒级时间戳
时区提示
- 请确认源值使用的是秒还是毫秒，混用 10 位和 13 位时间戳是日期出错的常见原因。
- 将人类可读日期转换为时间戳时务必确认目标时区，尤其涉及日志、定时任务和跨地域系统。
使用场景
技术原理
Unix 时间戳计量从 Unix 纪元（定义为 1970-01-01T00:00:00Z）起经过的时间，POSIX 时间以此作为零点来标记此后每一个时刻。POSIX 时间刻意忽略闰秒：每个日历日固定按 86,400 秒计算，因此跨越闰秒插入的两个时间戳与严格原子钟计数之间会有一秒偏差，但换来的好处是纪元秒与 UTC 日历字段之间的转换可以干净地通过除以 86,400 取模来完成。 日常最常见的两种格式是秒级（当前为 10 位数字，如 1717000000）和毫秒级（13 位数字，如 1717000000000）。JavaScript 的 Date.now() 返回自纪元以来的毫秒数，`new Date(ms)` 也接受毫秒；而 Unix `date +%s`、Go 的 time.Unix 以及大多数数据库 TIMESTAMP 列使用秒。基于长度的判断是常用的消歧方式：10 位数值按秒解读落在 2001-2286 年范围内，同一数值按毫秒解读则在 1970 年内。 展示时间戳需要时区。UTC 以 `Z` 后缀表示；其他偏移量使用 `±HH:MM` 格式（如 `+08:00` 表示中国标准时间，`-05:00` 表示美国东部标准时间）。ISO 8601 允许多种可选分隔符，而 RFC 3339 是更严格的规范，固定了格式，这就是为什么 API 规范通常要求使用带有显式偏移量的 RFC 3339。使用 32 位有符号整数存储纪元秒的遗留系统将在最大正值 2147483647 时溢出，对应 2038-01-19T03:14:07Z（即 2038 年问题）；64 位存储则将边界推至远超人类相关的范围。
- Unix 纪元固定为 1970-01-01T00:00:00Z，POSIX 时间忽略闰秒，因此每个日历日固定按 86,400 秒计算。
- JavaScript Date.now() 返回毫秒；`Math.floor(Date.now() / 1000)` 可转换为秒级时间戳。
- 2038 年边界：有符号 32 位时间戳在 2147483647 = 2038-01-19T03:14:07Z 时溢出；64 位存储可避免此问题。
- ISO 8601 与 RFC 3339 对比：RFC 3339 是更严格的 ISO 8601 规范，要求显式偏移量（`Z` 或 `±HH:MM`），是 API 和日志的首选。
- ECMAScript Date 限于纪元前后各 ±100,000,000 天（约 ±273,785 年），`new Date(8.64e15)` 和 `new Date(-8.64e15)` 是绝对边界。
- JWT 的 `exp`、`iat` 和 `nbf` 声明、`Cache-Control: max-age` 以及 Cookie 的 `Expires` 均使用 Unix 秒（RFC 7519、RFC 7234），因此可直接与 `Math.floor(Date.now()/1000)` 进行加减运算。
- 时区影响渲染后的日期时间，但不影响时间戳值本身；同一纪元秒在 UTC+8 和 UTC-5 下会显示为不同的当地时间。
示例
10 位 Unix 时间戳转可读日期
输入： 1781526600
UTC: 2026-06-15 12:30:00
北京时间 (UTC+8)： 2026-06-15 20:30:00
ISO 8601: 2026-06-15T12:30:00Z
POSIX: IEEE 1003.1 将 Unix 时间定义为自 1970-01-01 00:00:00 UTC（Epoch）以来的秒数
ISO: ISO 8601 定义了 YYYY-MM-DDThh:mm:ssZ 格式，用于无歧义地表示日期时间日期反向转回时间戳
输入： 2026-01-01 00:00:00 (UTC)
秒（10 位）： 1767225600
毫秒（13 位）： 1767225600000
Unix 命令： date -d @1767225600
注意： JavaScript Date.getTime() 返回毫秒；Python time.time() 返回秒（浮点数）
POSIX: time_t 类型传统上是 32 位或 64 位有符号整数区分秒和毫秒
1781526600 -> 10 位，秒 -> 2026-06-15 12:30:00 UTC
1781526600000 -> 13 位，毫秒 -> 2026-06-15 12:30:00.000 UTC
常见 bug：把 13 位数值当作秒解析，年份会变成约 74,000 年
快速判断：10-11 位是秒（1970-2286），13 位是毫秒（JavaScript 默认）解析 JWT 的 exp 声明
JWT payload: { "exp": 1798617600 }
解码后： 2027-01-01 00:00:00 UTC
当前时间： 1781526600
剩余有效期： 17,091,000 秒（约 198 天）
RFC: RFC 7519 第 2 节将 NumericDate 定义为自 Epoch 以来的秒数Y2038 边界检查
32 位有符号最大时间戳： 2147483647
解码后： 2038-01-19 03:14:07 UTC
再加 1 秒： 2147483648 -> 老式 32 位系统溢出
解决方案： 使用 64 位 time_t（现代 Linux/macOS 默认），或以 ISO 8601 字符串存储
POSIX: 32 位 time_t 系统在 2038-01-19 之后会发生回绕常见问题
什么是 Unix 时间戳？
指自 1970-01-01 00:00:00 UTC（即「Unix 纪元」）以来经过的秒数。JavaScript 和许多 API 使用的是基于同一纪元的毫秒数（Unix 时间戳 × 1000）。页面两种都接受，并显示对应的本地时间和 UTC 时间。
秒、毫秒、微秒、纳秒有什么区别？
不同系统使用不同精度。Unix 的 `time()` 返回秒；JavaScript 的 Date.now() 返回毫秒；Java 的 Instant 支持纳秒。页面按位数自动识别：10 位 = 秒（覆盖 2001-2286 年），13 位 = 毫秒，16 位 = 微秒，19 位 = 纳秒。
为什么 2038 年 1 月 19 日很重要？
这就是「2038 年问题」：32 位有符号的 Unix 时间戳会在 2038-01-19 03:14:07 UTC 溢出。仍在使用 32 位 time_t 的系统会回退到 1901 年。现代 64 位系统在数十亿年内都不会受影响，但遗留的嵌入式系统需要修复。
时区是怎么处理的？
Unix 时间戳本质上就是 UTC。页面会显示你的本地时间和 UTC 时间，并允许你额外选择任意 IANA 时区（Asia/Shanghai、America/New_York、Europe/London）展示。夏令时会按时区自动应用。
为什么解析「YYYY-MM-DD」时有些地方默认按 UTC 处理？
ISO 8601 格式中不带时区的日期本身就是有歧义的。JavaScript 的 Date 构造函数把仅含日期的字符串视为 UTC，把含日期时间的字符串视为本地时间——这是「差一天」类 bug 的著名来源。本页面会明确标注实际使用的时区。
换算是在本地完成的吗？
是的。计算依赖 JavaScript 的 Date 和 Intl.DateTimeFormat，不会上传任何时间戳。
可以生成未来的时间戳吗？
可以。选择一个未来日期，页面会返回对应的时间戳。适用于设置 JWT 的 exp 字段、cron 任务的测试日期，或代码中的缓存过期时间。