Unix 时间戳转换器 — 时间戳转日期，日期转时间戳
把秒、毫秒、微秒或纳秒级时间戳转换为任意时区的日期，也可反向转换。实时时钟、批量模式、代码片段。
时间戳转日期
日期转时间戳
日、周、月、年的开始和结束
批量转换
| 1700000000 | s | |
| 1760572800000 | ms | |
| -1 | s | |
| 2038-01-19 03:14:07 | 日期 | |
| 0 | s |
在代码中获取当前时间戳
Math.floor(Date.now() / 1000) // seconds Date.now() // milliseconds
完全在浏览器中运行。你输入的任何内容都不会发送给我们或被存储。 浏览全部免费工具.
发现问题，或者觉得哪里可以更好？每条消息我们都会阅读，并尽快修复。
这款 Unix 时间戳转换器可以把 epoch 值转换为可读的日期，也能把日期转换回 epoch 值，支持 UTC、你所在的时区，以及浏览器所知的约 400 个 IANA 时区中的任意一个。粘贴 1760572800、1760572800000 或日志行中的 19 位纳秒值：单位会根据位数自动识别，值有歧义时你也可以手动指定。
超大和特殊的值也能精确处理。数字按 BigInt 解析，因此纳秒时间戳会保留最后几位，而不会被四舍五入；1970 年之前的负时间戳会向下取整到正确的毫秒；超出 JavaScript 日期范围（约公元前 271,821 年至公元 275,760 年）的值会被报告为超出范围，而不是显示为 "Invalid Date"。时区偏移（包括夏令时变化）来自浏览器自身的时区数据。你输入的任何内容都不会离开本页。
使用方法
- 把时间戳粘贴到第一个输入框中。表格会以 UTC、你的时区、所选时区、ISO 8601、RFC 2822 和相对时间显示它。
- 如果单位识别错误（12 位数字既可能是公元 5138 年之后的秒，也可能是 1973 年的毫秒），请在“单位”菜单中选择。
- 反向转换时，按 YYYY-MM-DD HH:mm:ss 格式输入日期，并选择它所属的时区；带 Z 或偏移量的 ISO 字符串会按原样读取。
- 用起止时间表处理“本月所有数据”之类的范围查询，用批量框处理 CSV 或日志中的一列值。
- 用对应按钮复制任意值，或复制你所用语言的代码片段，在代码中获取当前时间戳。
常见问题
什么是 Unix 时间戳？
Unix 时间戳（epoch 时间）是自 1970 年 1 月 1 日 00:00:00 UTC 起经过的秒数，不计闰秒。它没有时区：同一时刻在任何地方的时间戳都相同，这也是数据库和 API 使用它的原因。许多系统改为存储毫秒（JavaScript 的 Date.now()、Java 的 currentTimeMillis），还有一些存储微秒或纳秒。
如何判断时间戳是秒还是毫秒？
数位数。当前的秒级时间戳有 10 位，毫秒 13 位，微秒 16 位，纳秒 19 位。本工具会自动按这些界限识别。唯一有歧义的是 11 到 12 位，它要么是遥远未来的秒，要么是 1970 年代初的毫秒；这种情况请手动选择单位。
什么是 2038 年问题？
以有符号 32 位整数存储 Unix 时间的系统，最多只能数到 2,147,483,647，即 2038 年 1 月 19 日 03:14:07 UTC。再过一秒，数值就会回绕为负数，被读成 1901 年 12 月。现代操作系统、编程语言和数据库都使用 64 位时间，但旧的嵌入式设备、文件格式以及声明为 32 位 INT 的数据库列仍存在这个问题。
Unix 时间戳包含闰秒吗？
不包含。Unix 时间把每一天都视为正好 86,400 秒，因此闰秒不被计入，发生闰秒时时间戳会重复或停顿一秒。这让日期计算变得简单，代价是与原子时（TAI）相差累计的闰秒数，目前为 37 秒。对几乎所有应用开发来说，这都无关紧要。
Unix 时间戳可以是负数吗？
可以。负值从 1970 年往回数：-1 是 1969 年 12 月 31 日 23:59:59 UTC，-86400 是那一天的开始。大多数语言都能正确处理负时间戳，但一些旧 API 和电子表格函数会拒绝它们，所以在把出生日期或历史日期存为 epoch 值之前，请先确认。
为什么转换出来的时间差了几个小时？
几乎总是时区搞混了：时间戳本身是对的，但你期望看到本地时间时它却以 UTC 显示，或者本地日期字符串被当作 UTC 解析了。时间戳本身从不携带时区。请检查这里的时区选择器，并在代码中确保不带偏移量的日期字符串按你想要的时区解析。
秒、毫秒、微秒、纳秒：各由谁使用
• 秒（10 位）：Unix 和 POSIX 的 time()、PHP 的 time()、Python 的 int(time.time())、PostgreSQL 的 EXTRACT(EPOCH)、JWT 的 exp/iat/nbf 声明、大多数 HTTP API。
• 毫秒（13 位）：JavaScript 的 Date.now()、Java 的 System.currentTimeMillis()、Elasticsearch 和许多 JSON API、Kafka 记录时间戳。
• 微秒（16 位）：PostgreSQL 内部的时间戳存储、Python datetime 的精度、Google BigQuery 的 TIMESTAMP_MICROS。
• 纳秒（19 位）：Go 的 time.UnixNano()、Python 的 time.time_ns()、InfluxDB 和 Prometheus remote-write、Linux 的 clock_gettime。JavaScript 的 number 无法精确容纳这些值，这也是本工具将它们按 BigInt 解析的原因。
当两个系统的结果相差 1,000 倍时，一个用的是秒，另一个用的是毫秒。大多数“日期显示为 1970 年”和“日期显示为 50,000 年”的 bug 都源于这一个错误。
时区和夏令时：可能出什么问题
把时间戳转换为本地时间总是明确无歧义的：一个时刻在每个时区只对应一个挂钟读数。反过来则不然。时钟拨快时，切换当天的 02:30 这样的本地时间根本不存在；时钟拨回时，01:30 会出现两次。
本转换器遵循与 JavaScript Temporal API 默认行为相同的规则：被跳过的时间按切换前的偏移量读取（因此 02:30 会变成夏令时的 03:30），重复的时间取第一次出现。如果你的代码使用不同的规则，每年这两个日期前后的结果可能相差一小时。
最稳妥的做法是：以 UTC 时间戳或带明确偏移量的 ISO 8601 字符串存储和传输时刻，只在显示时才转换为本地时间，并使用 America/Toronto 这样的 IANA 时区名称，而不是 -05:00 这样的固定偏移量——后者一年中有一半时间是错的。
ISO 8601、RFC 2822 与 Unix 时间
ISO 8601（2026-10-16T08:00:00Z 或 2026-10-16T04:00:00-04:00）按文本排序就是正确的时间顺序，没有歧义，也是 JSON API、HTML datetime 属性和大多数数据库所期望的格式。只要值可能给人看，就用它。
RFC 2822（Fri, 16 Oct 2026 08:00:00 +0000）是电子邮件和 HTTP 头部的格式。它可读，但按文本排序不正确，而且只为 1900 年及以后的年份定义。
Unix 时间戳最紧凑，比较起来最快，但没有转换器就无法阅读，也看不出它的单位。一条合理的规则：系统内部用 Unix 时间，系统边界处用 ISO 8601。
相关免费工具
- Cron 表达式生成器 — 用下拉菜单生成 cron 定时计划，或粘贴现有表达式，用通俗语言解读，并查看接下来 10 次运行时间（本地时区和 UTC）。免费，在浏览器中运行。
- JWT 解码器 — 解码 JWT 的头部和载荷，用通俗语言显示过期时间，验证 HS、RS、PS 和 ES 签名，或签发新令牌。任何数据都不会离开浏览器。
- UUID 生成器 — 批量生成 UUID v4 或按时间排序的 v7、ULID 和 NanoID，或粘贴一个 ID 查看其版本和内嵌的时间戳。
- 进制转换器 — 在二进制、八进制、十进制、十六进制、32 进制、36 进制以及任意 2–36 进制之间转换任意大小的整数，并显示补码。