怎么用
- 页面顶部显示当前的 Unix 时间，每秒更新。点暂停可以把它定住，方便复制。
- 把时间戳粘贴到输入框里，工具会说明它按什么单位识别，并给出 UTC 时间、本地时间、RFC 2822 格式，以及距现在多久。
- 也可以粘贴 ISO 8601 格式的日期，比如 2023-11-14T22:13:20Z，得到对应的时间戳。
- 反过来，在日期转时间戳里选好日期和时间，并说明它是本地时间还是 UTC。
什么是 Unix 时间戳
Unix 时间是从 1970 年 1 月 1 日 00:00:00 UTC（称为「纪元」）起经过的秒数。同一时刻，它在地球上任何地方都相同；只有把它转换成日历日期和钟点时，时区才会起作用。这正是服务器、数据库和日志用它来记录时间的原因。
北京时间 = UTC + 8 小时
中国全境使用北京时间，也就是 UTC+8，不实行夏令时。所以 UTC 时间加 8 小时就是北京时间。时间戳 1700000000 对应 UTC 2023 年 11 月 14 日 22:13:20，也就是北京时间 11 月 15 日 06:13:20，日期已经跨到了第二天。排查线上问题时，日志里的时间是 UTC 还是北京时间，经常是差 8 小时的根源。
单位怎么判断
不同系统用的单位不同：Unix 和大多数数据库用秒，JavaScript、Java 用毫秒，一些日志系统和 Go 用微秒或纳秒。对于现在的日期，它们分别是 10、13、16、19 位。本工具据此判断：不超过 11 位按秒，12–14 位按毫秒，15–17 位按微秒，18–19 位按纳秒，状态栏会写明它选了哪种。纳秒值超出了 JavaScript 能精确表示的范围，所以先用任意精度整数读取，再显示到毫秒。
闰秒
Unix 时间不计闰秒：每天都按正好 86,400 秒计算，插入闰秒时相当于有一秒被重复。所以时间戳转日期只是简单的算术，结果和操作系统一致。代价是两个时间戳之间实际经过的时间，可能比相减的结果多出其间的闰秒数，自 1972 年以来一共加过 27 个闰秒。
示例
| 输入 | 识别为 | UTC |
|---|---|---|
1700000000 | 秒 | 2023-11-14T22:13:20.000Z |
1700000000000 | 毫秒 | 2023-11-14T22:13:20.000Z |
1700000000123456789 | 纳秒 | 2023-11-14T22:13:20.123Z |
1700000000.5 | 带小数的秒 | 2023-11-14T22:13:20.500Z |
-86400 | 秒，纪元之前 | 1969-12-31T00:00:00.000Z |
2147483647 | 秒 | 2038-01-19T03:14:07.000Z |
最后一行是 32 位有符号整数能表示的最大值。仍用 32 位存储 Unix 时间的系统，会在 2038 年 1 月 19 日这一秒之后溢出，这就是「2038 年问题」。
反过来，2023-11-14T22:13:20Z 是 1700000000 秒，或者 1700000000000 毫秒；写成 RFC 2822 格式是 Tue, 14 Nov 2023 22:13:20 +0000。
局限
- 位数有歧义的情况。 10 位数一律按秒理解。1970 年初的毫秒级时间戳（不足 12 位）会被误判，这种值在测试数据之外很少见。
- 精度到毫秒。 微秒和纳秒会截到毫秒，这是 JavaScript 日期的精度。
- 不计闰秒，与 POSIX 标准和所有主流操作系统一致。
- 本地时间使用你设备的时区设置。想看同一时刻在其他城市是几点，请用时区换算工具。
常见问题
怎么区分秒级和毫秒级时间戳？
看位数：现在的时间戳按秒是 10 位，按毫秒是 13 位。工具会自动判断并说明用的是哪种。
时间戳转出来的时间差了 8 小时？
时间戳本身对应的是 UTC 时间，北京时间要再加 8 小时。本工具同时列出 UTC 和你设备所在时区的时间，对照着看就不会弄错。
什么是 2038 年问题？
32 位有符号整数最多只能数到 2,147,483,647 秒，也就是 UTC 2038 年 1 月 19 日 03:14:07。用这种方式存储时间的系统，过了这一刻就会溢出。
负数时间戳能转换吗？
能。负数表示 1970 年 1 月 1 日之前的时刻，-86400 就是 1969 年 12 月 31 日。
会考虑闰秒吗？
不会，Unix 时间本身也不考虑。每天都按正好 86,400 秒计算。