关于 时间戳与时区转换
日期与时间戳转换工具接收一个值 —— 以秒或毫秒计的 Unix 时间戳、ISO 8601 字符串，或任何浏览器能解析的日期串 —— 然后把同一个时刻同时呈现为六种形态：ISO 8601、本地时区、UTC、你指定的时区、Unix 秒和 Unix 毫秒。它还会告诉你它把输入当成了哪种格式，而这往往是整页最有价值的一行。
时间戳只是自某个纪元起流逝的单位数。它本身不携带时区、不携带日历，也不携带单位；这三样都活在系统之间的约定里，一旦约定没有写下来就会出事。故障主要有两类：一是单位，秒和毫秒相差 1000 倍，而差了这个倍数的值照样解析得动，只不过落在 1970 年或第 58 个千年；二是偏移量，不带偏移量的墙钟字符串，在每一台读它的机器上都代表不同的时刻。
如何使用这个开发者工具
- 把值粘贴到「日期或时间戳」输入框。纯数字会被当作 Unix 时间戳，其余内容交给浏览器的日期解析器。
- 设置目标时区。默认是 Asia/Shanghai，任何 IANA 时区名都可以填。
- 点击「解析」，先看「识别格式」。Unix 秒、Unix 毫秒和 ISO 8601 都是无歧义的；凡是被标成「浏览器日期格式」的，都走了一条规则并未标准化的兜底解析路径。
- 把本地那一行、UTC 那一行和你指定时区那一行放在一起比。日历日期不一样的地方，差异是真实存在的，下游报表正是从这里开始出错。
- 需要参照点时用「现在」按钮填入当前时刻，再把整块结果复制走，省得下一个人重新换算。
实例：一个 Unix 时间戳，六种表示
从日志行里取出的一个十位数值，目标时区设为 Asia/Shanghai。十位数低于秒／毫秒判定阈值，因此按秒来读。
1774000000
Asia/Shanghai识别格式 Unix 秒
ISO 8601 2026-03-20T09:46:40.000Z
UTC 2026年3月20日星期五 UTC 09:46:40
Asia/Shanghai 2026年3月20日星期五 GMT+8 17:46:40
Unix 秒 1774000000
Unix 毫秒 1774000000000两个时区的日历日期恰好相同，这是运气而不是规律：09:46 UTC 在一天中足够靠前，加 8 小时还没跨过午夜。把 1700000000 放进同样这两个时区试试 —— UTC 是 11 月 14 日，Asia/Shanghai 却是 11 月 15 日。一个时刻，两个日期，一张自相矛盾的日报。
单位与格式对照
纯数字小于 100000000000 时按秒读，大于等于时按毫秒读。这是启发式规则而非标准：「自 1970 年起的秒数」要到公元 5138 年才涨到 11 位，而毫秒数在 1973 年 3 月就已经是 11 位了。
| 格式或单位 | 示例 | 如何被解读 |
|---|---|---|
| Unix 秒 | 1774000000 | 低于阈值，按秒读：2026-03-20T09:46:40Z |
| Unix 毫秒 | 1774000000000 | 达到阈值，按毫秒读：同一个时刻 |
| 阈值本身 | 99999999999 与 100000000000 | 前者按秒读，落在公元 5138 年；后者按毫秒读，落在 1973-03-03T09:46:40Z |
| ISO 8601 | 2026-09-21T14:30:00+08:00 | 无歧义。该标准范围很宽，也允许 20260921T143000+0800 这类紧凑写法 |
| RFC 3339 | 2026-09-21T14:30:00+08:00 | ISO 8601 面向互联网的严格子集：完整日期、完整时间、必须带偏移量，UTC 可写 Z |
| RFC 2822 | Mon, 21 Sep 2026 14:30:00 +0800 | 邮件头和较老的工具链。与上面两行是同一时刻：2026-09-21T06:30:00Z |
| HTTP-date | Mon, 21 Sep 2026 06:30:00 GMT | Date 和 Last-Modified 响应头唯一允许的写法，永远以 GMT 表示 |
| 纯日期 | 2026-09-21 | 按 UTC 零点解析：2026-09-21T00:00:00Z |
| 日期时间但无偏移量 | 2026-09-21T14:30:00 | 按本地时间解析，同一串文本在别的时区是另一个时刻 |
常见问题排查
结果落在 1970 年 1 月，或者落在公元 58185 年。
成因 单位差了 1000 倍。把 1774000000 当毫秒读会得到 1970-01-21T12:46:40Z，把 1774000000000 当秒读会得到 58185-10-27T09:46:40Z。
解决办法 数位数：对 2001 到 2286 年之间的日期，10 位是秒，13 位是毫秒。而当你负责产出时间戳时，请把单位写进字段名 —— 用 created_at_ms，而不是 created_at。
纯日期串和日期时间串差了整整一天。
成因 ECMAScript 规定 2026-09-21 按 UTC 解析，而 2026-09-21T00:00:00 按本地时间解析。在 Asia/Shanghai，后者是 2026-09-20T16:00:00Z —— 前一天。
解决办法 永远不要依赖这个区别。要存储或传输的日期时间一律补上显式偏移量或 Z；纯日期值应当当作日历日期，而不是时刻。
同一个字符串在这里解析成功，换个地方却被拒绝或解析成别的值。
成因 ISO 8601 之外，日期解析是实现自定义的。用空格代替 T 的 2026-09-21 14:30:00 在 V8 里能解析、在别处会失败；09/21/2026 被读成 9 月 21 日，而 21/09/2026 直接是 Invalid Date；2026-09-21T23:59:60Z 会被彻底拒绝，因为 Unix 时间里没有闰秒。
解决办法 把「识别格式」当成警告灯。只要它显示的不是 Unix 秒、Unix 毫秒或 ISO 8601，就先把值规范成带显式偏移量的 ISO 8601，再让它流向别处。
夏令时切换附近的墙钟时间，换算结果不对劲。
成因 不带偏移量的字符串要拿本地时区来定位，而本地时区一年里有一个空洞和一个重叠。在 America/New_York 的机器上，2026-03-08T02:30:00 根本不存在，会被推到 07:30Z；2026-11-01T01:30:00 存在两次，会被悄悄取成第一遍，即 05:30Z。
解决办法 把偏移量带上。2026-11-01T01:30:00-04:00 和 2026-11-01T01:30:00-05:00 是两个不同的时刻，能区分它们的只有偏移量。
适合用这个工具的场景
- 把日志、数据库字段或 JWT 声明里的原始时间戳，变成一个你能推理的日期。
- 确认某个过期时间或回填窗口，在客户所在时区里是否落在你以为的位置，而不是在你自己的时区里。
- 一次粘贴就终结两个服务之间关于「秒还是毫秒」的争论。
- 生成一个格式正确的 ISO 8601 值，放进测试夹具、查询参数或缺陷报告。
应该换用别的工具的场景
- 推算定时任务下一次什么时候跑。请把调度规则交给 Cron 表达式解析器，它才处理周期和夏令时切换。
- 在程序内部测量耗时。墙钟时间可能往回跳，测时长请用 performance.now()、System.nanoTime() 这类单调时钟。
- 跨月份、跨时区的日历运算，比如「1 月 31 日加一个月」。请用 Temporal、java.time 这类把规则编码进去的现代日期库。
隐私与数据处理
所有计算都在当前浏览器标签页内完成，使用浏览器自带的 Intl 时区数据。没有任何值被上传，标签页关闭后不留痕迹。从生产日志里摘出来的时间戳，同一行通常还带着请求 ID、用户 ID 或 IP；只粘贴时间戳就够了。
相关开发者工具
常见问题
不数位数的话，怎么分辨秒和毫秒？
换算一遍看年份。落在 1970 年说明毫秒被当成了秒，落在几千年之后说明反过来了。数位数是速判，年份才是证据。
为什么 Unix 秒那一行把小数部分丢了？
Unix 秒是对毫秒值向下取整得到的，所以 1774000000.5 在秒那一行显示为 1774000000，而 ISO 和毫秒两行保留了 .500。只要亚秒精度有意义，就用毫秒值。
2038 年问题会影响我吗？
有符号 32 位秒计数器会在 2038-01-19T03:14:07Z 溢出。本工具用 JavaScript 数字类型，不受影响；但 C 的 time_t、较老的嵌入式设备和 32 位整型列仍会中招。请把时间戳存成 64 位整数或数据库原生时间戳类型。
应该存 UTC 还是本地时间？
时刻按 UTC 存，同时在本地墙钟有意义的场景下把时区单独存一列 —— 约在 Europe/Berlin 09:00 的会议跨过夏令时切换后仍然是 09:00，单凭一个 UTC 时刻表达不出这件事。本地时间只在展示时换算。
支持负数时间戳吗？
支持。负值表示 1970-01-01T00:00:00Z 之前的日期，比如 -1 就是 1969-12-31T23:59:59Z。但许多系统即便能存下负值，在格式化或日期运算环节仍会出错，请先把整条链路验一遍。
为什么每次刷新相对时间都会变？
「6 个月后」这类说法是按你点击「解析」那一刻的时钟算出来的。它只是展示层的辅助而不是数据；要存储或传输的应该是绝对时间戳，相对形式在展示时再算。