时间
Unix 时间戳转换
10 位的秒和 13 位的毫秒都直接支持，不用先告诉它单位；同一时刻会同时列出 UTC、本地时间和 ISO 8601 三种写法。
怎么用
- 在左侧输入时间戳，右侧会自动显示日期。
- 也可以输入 2026-10-17 09:30:00 这样的日期，反查时间戳。
- 点「使用当前时间」取此刻的时间戳。
秒、毫秒，以及 2038 年
Unix 时间从 1970 年 1 月 1 日 UTC 起算秒数，刻意忽略闰秒。很多系统把这个计数存成有符号 32 位整数，最大值是 2,147,483,647，会在 2038 年 1 月 19 日到达。仍在使用 32 位时间戳的系统，那天会回绕到 1901 年。这和千年虫是同一类问题，只是留给修补的时间更少。
为什么时间戳看起来差了几个小时
Unix 时间戳不带时区，它是一个绝对时刻。变的是本地渲染。同一个数值在伦敦显示 09:00，在上海是 17:00，在奥克兰是第二天 01:00。当某个存下来的时间「看起来差了八小时」，几乎总是存储正确、而显示时用了错误的时区。
从数字本身判断单位
不需要知道这个时间戳是谁生成的，看数量级就知道。十位是秒（当前约 17 亿）。十三位是毫秒。十六位是微秒。十九位是纳秒。落在 1970 年代的值，通常意味着某个空字段被写成了 0。
换算结果整整差几个小时，说明时间戳没问题、显示有问题：它的定义就是 UTC，而浏览器按本地时区渲染。存 UTC、显示本地，永远不要存一个不带偏移量的本地时间。
常见问题
Unix 时间戳到底是什么？
从 1970-01-01 00:00:00 UTC 起经过的秒数，不计闰秒。它与时区无关，所以数据库普遍存这个值。
秒还是毫秒？
两种都行。10 位按秒解读，13 位按毫秒解读，下方提示会说明实际按哪种处理。
为什么我的时间戳差了几个小时？
时间戳本身是 UTC，而「本地」那一行按你机器的时区渲染。与 UTC 那行对比就能判断是时区问题还是值本身错了。
这个工具处理闰秒吗？
不处理。Unix 时间忽略闰秒，按每天正好 86400 秒计算，这也是它与天文时逐渐偏离的原因。
2038 年会发生什么？
32 位有符号时间戳在 2038 年 1 月 19 日溢出。任何仍在用 32 位字段存秒数的系统会跳回 1901 年。