时间戳转换器
Unix 秒/毫秒、ISO 8601 与本地时间三向互转,自动识别秒和毫秒,并列出同一时刻在各时区的读数与当时的 UTC 偏移。
秒或毫秒都行,会自动识别
例如 2026-08-15T10:00:00Z 或 2026-08-15 18:00
| Unix 秒 | — | |
| Unix 毫秒 | — | |
| ISO 8601 (UTC) | — | |
| ISO 8601 (本地) | — | |
| 星期 | — | |
| 距现在 | — |
各时区对照
| 时区 | 当地时间 | UTC 偏移 |
|---|---|---|
| UTC | — | — |
| Asia/Shanghai | — | — |
| Asia/Tokyo | — | — |
| Asia/Singapore | — | — |
| Europe/London | — | — |
| Europe/Berlin | — | — |
| America/New_York | — | — |
| America/Los_Angeles | — | — |
全部换算由浏览器完成,没有任何请求。
容易出错的三个地方
秒还是毫秒是按位数猜的,而且把猜的结果显示出来: 10 位是秒(一直到 2286 年),13 位是毫秒。把毫秒填进期望秒的字段,时间会跑到公元 55000 年; 反过来会掉回 1970 年附近 —— 这是时间戳相关 bug 里最常见的一种,所以这里不静默处理。
时区那张表算的是同一个瞬间在各地的挂钟时间,
并且给出那一刻该时区的实际 UTC 偏移。所以夏令时会如实显示出来 ——
America/New_York 在一月是 UTC−05:00,七月是 UTC−04:00,
而写死「−5」的表格全年都是错一半。任意 IANA 时区都能加进来:整个时区数据库就在你的浏览器里。
「ISO 8601(本地)」这一行是手工拼的,因为 toISOString() 永远输出
UTC 的 Z 后缀,拿它当本地时间用是另一类经典错误。这里输出的是带真实偏移的本地时间,
比如 2026-08-15T18:00:00+08:00。
没有引入 moment-timezone 之类的库:浏览器早就内置了完整的 IANA 时区数据库,
Intl.DateTimeFormat 就能查。多带几百 KB 会过期的规则表,
换来的只是同样的答案。