使用方法
这个世界时钟不做换算，只做并列：同一个绝对时刻，在十几个时区里各自读出来是多少点。
- 「参考时刻」默认填 2026-11-01T05:30（示例值，按 UTC 解释），也就是 2026 年 11 月 1 日 05:30 协调世界时。这里用的是 UTC 而不是你的本地时间，是为了让不同地区的人打开页面看到的是同一张表。
- 下方城市勾选框默认全选 12 个时区，覆盖 UTC+14 的
Pacific/Kiritimati到 UTC−11 的Pacific/Niue，跨度正好 25 小时。 - 表格按 UTC 偏移从东到西排列，四列分别是城市名、IANA 时区名、由
timeZoneName:'shortOffset'给出的短偏移（如GMT+8）、当地时刻；最后一列「日期偏移」标出该时区此刻比 UTC 早一天、晚一天还是同一天。 - 点「设为当前时刻」把参考值切到现在的 UTC 整分，并把输入框清空进入实时模式；点「载入 DST 示例」回到默认的 2026-11-01 05:30。
- 把你浏览器上报的时区填进最上面的只读框（由
Intl.DateTimeFormat().resolvedOptions().timeZone读出），表里对应的那一行会高亮，方便和别的城市对照。
这个世界时钟能解决什么问题
一是跨时区排会议。约一次三地同时在线的会，最怕的是"以为大家都上班"。把参考时刻设成你打算提议的那一刻，一眼就能看出哪个城市的当地时刻落在凌晨。
二是看懂"为什么对方说的日期不一样"。同一个瞬间，Pacific/Kiritimati 已经是 11 月 1 日晚上 19:30，而 Pacific/Niue 还停在 10 月 31 日傍晚 18:30——两张日历差一天，钟面差 25 小时。这类沟通事故基本都是没分清"绝对时刻"和"当地日历"。
三是避开夏令时切换的那两天。每年两次，纽约、伦敦、巴黎、悉尼、奥克兰都会在某个凌晨把钟拨快或拨慢一小时。如果排期正好落在那一天，同一句"上午 9 点"可能对应两个不同的时刻，或者干脆不存在。表里给出的 UTC 偏移能让你提前发现这件事。
四是校验程序里的时区配置。写日志、跑定时任务时把 GMT+8 这种固定偏移写死，到夏令时切换当天就会整体偏一小时。这份世界时钟把每个城市的 IANA 时区名 直接列给你，配置时照抄名字即可，规则交给时区数据库维护。
本页不做这些事：不做两地之间的双向换算（那属于"时区转换器"的职责）、不做时间戳与日期字符串的解析、不记录你查过哪些城市。它只回答一个问题——某个绝对时刻，各地分别读到几点几分。
原理：为什么必须用 IANA 时区名而不是 GMT+8
整个工具的计算只依赖一个标准 API：Intl.DateTimeFormat，通过 timeZone 选项指定 IANA 时区标识符。它背后的数据是 IANA 时区数据库（tz database，也叫 zoneinfo / tzdata），这份数据记录的不是"某个地方永远比 UTC 快几小时"，而是某地在历史上各个时间段分别用哪个偏移、哪一次切换在哪个瞬间生效。
这就是为什么 GMT+8、UTC-05:00 这类固定偏移不能用于严肃场景：它只能表达一个恒定差值，无法携带夏令时规则，也无法记载某国改过标准时间的历史。写死 GMT-5 的纽约程序，在 3 月 8 日之后会整体偏一小时，直到 11 月 1 日又自己"对上"，但没有任何代码告诉它为什么。反过来，America/New_York 这个名字把全部规则都包含了：什么时候切、切多少、将来会不会再改，全由 tzdata 更新决定。
偏移的读取方式也有讲究。本页同时用两种 timeZoneName 取值：'shortOffset' 给出适合展示的短形式（GMT+8、GMT+5:30、GMT-4），'longOffset' 给出带前导零的完整形式（GMT+08:00、GMT+05:30、GMT-04:00）。两者在 30 分钟级偏移上都会保留 :30——印度是 UTC+5:30、尼泊尔是 UTC+5:45，这类"非整点偏移"正是固定写死 整点 的代码最容易翻车的地方。
当地时刻的格式化同样交给 Intl.DateTimeFormat，用 formatToParts() 把年、月、日、时、分、秒逐字段取出来，而不是自己拿偏移量做加减。原因是：用偏移做加减只能得到"另一个时区的钟面"，得不到当地的日历。跨日界线的日期归属、二月的天数、闰年，全都要由同一套规则算出来才不会互相打架。「日期偏移」这一列就是拿当地日期和 UTC 日期直接比出来的差值。
最后一点：Intl 支持的时区列表取决于运行环境的 ICU 数据版本，而 ICU 会随 tzdata 更新。所以同一条 America/New_York 在不同年份的浏览器里，对"2027 年某天几点"的回答可能不同——这不是 bug，而是规则真的被改过。本页所有关于具体日期的数字都以当前环境输出的结果为准，页面上写的示例值也标注了对应年份。
夏令时边界：被跳过的一小时与出现两次的一小时
夏令时（DST）切换不是"平滑调整"，而是在某个瞬间把钟面直接平移一小时，于是当地钟表上必然出现一段异常区间。有两种，方向相反：
春季拨快——整点被跳过。2026 年 3 月 8 日，美国东部夏令时开始。第二个周日凌晨，当地钟表从 01:59:59 的下一秒直接跳到 03:00:00。对应的 UTC 瞬间是 2026-03-08T07:00:00Z，从这一刻起 America/New_York 的偏移由 GMT-5 变为 GMT-4。这就意味着当地日历上的 02:00:00 到 02:59:59 这一整段根本不存在。程序里如果按当地字符串写死"每天 02:30 执行一次"，这一天它要么不执行、要么按实现不同被顺延到 03:30 或跳过。
秋季拨慢——同一时刻出现两次。2026 年 11 月 1 日，美国东部夏令时结束。当地钟表从 01:59:59 走回 01:00:00，偏移由 GMT-4 变回 GMT-5。于是当地日历上的 01:00:00 到 01:59:59 这一段会出现两遍。以本页默认参考时刻为例：
2026-11-01T05:30:00Z→ 纽约当地 2026-11-01 01:30 GMT-04:00（还是夏令时，第一遍）；2026-11-01T06:30:00Z→ 纽约当地 2026-11-01 01:30 GMT-05:00（已回拨，第二遍）。
同一条"11 月 1 日 01:30"的当地时间字符串，对应两个相差一小时的绝对时刻。这就是所有日程系统在那一晚容易产生歧义的根源：当地字符串 → 绝对时刻的映射在这个区间内不是一一对应的。
下表列出 2026 年几个常用时区的切换瞬间与当地表现，UTC 那一列就是规则真正生效的时刻：
| 时区 | 方向 | 2026 年切换瞬间（UTC） | 当地钟表表现 |
|---|---|---|---|
| America/New_York | 拨快 | 2026-03-08 07:00 | 01:59:59 → 03:00:00，02:00～02:59 不存在 |
| America/New_York | 拨慢 | 2026-11-01 06:00 | 01:59:59 → 01:00:00，01:00～01:59 出现两次 |
| Europe/London | 拨快 | 2026-03-29 01:00 | 00:59:59 → 02:00:00，01:00～01:59 不存在 |
| Europe/London | 拨慢 | 2026-10-25 01:00 | 01:59:59 → 01:00:00，01:00～01:59 出现两次 |
| Europe/Paris | 拨快 | 2026-03-29 01:00 | 01:59:59 → 03:00:00，02:00～02:59 不存在 |
| Europe/Paris | 拨慢 | 2026-10-25 01:00 | 02:59:59 → 02:00:00，02:00～02:59 出现两次 |
| Australia/Sydney | 拨慢 | 2026-04-04 16:00 | 02:59:59 → 02:00:00，02:00～02:59 出现两次 |
| Australia/Sydney | 拨快 | 2026-10-03 16:00 | 01:59:59 → 03:00:00，02:00～02:59 不存在 |
| Pacific/Auckland | 拨慢 | 2026-04-04 14:00 | 02:59:59 → 02:00:00，02:00～02:59 出现两次 |
| Pacific/Auckland | 拨快 | 2026-09-26 14:00 | 01:59:59 → 03:00:00，02:00～02:59 不存在 |
| Asia/Shanghai | — | 全年无切换 | 全年固定 GMT+8，不参与夏令时 |
注意悉尼和奥克兰是南半球，它们的"拨快"发生在 10 月、"拨慢"发生在 4 月，和北半球正好相反。这也是把偏移写死最危险的地方——你无法用一个固定规则同时描述南北两个半球。
跨日界线与 25 小时时差
国际日期变更线两侧的时区，偏移可以相差到 25 小时，而不是常见的 24 小时之内。Pacific/Kiritimati（基里巴斯，UTC+14）是当前实际使用的最东时区之一，Pacific/Niue（纽埃，UTC−11）在西侧，两者钟面相差 25 小时。
在同一个绝对时刻，它们读出来的日期必然差一天：本页默认参考时刻 2026-11-01T05:30:00Z，基里巴斯读到的是 2026-11-01 19:30，而纽埃读到的是 2026-10-31 18:30。前者是 11 月 1 日晚上，后者还是 10 月 31 日傍晚——如果只看日期不看时区，这两条记录会被误判为"发生在相隔一天的两件事"。
这种"是不是同一天"的判断，本质上取决于你拿什么当基准。用 UTC 日期做基准，两个时刻都落在 11 月 1 日；用当地日期做基准，它们分属两天。写跨时区的统计、排行、账单日逻辑时，必须先把基准定死，否则同一条数据在不同机器上会算进不同的自然日。
时区偏移与日期偏移对照表
下表是默认参考时刻 2026-11-01 05:30 UTC下 12 个常用时区的读数，与页面打开时工具显示的完全一致（把它改成其他时刻，表里的值会跟着变）：
| 城市 | IANA 时区名 | UTC 偏移 | 当地时刻 | 日期偏移 |
|---|---|---|---|---|
| 基里巴斯/圣诞岛 | Pacific/Kiritimati | GMT+14 | 2026-11-01 19:30 | 0 |
| 奥克兰 | Pacific/Auckland | GMT+13 | 2026-11-01 18:30 | 0 |
| 悉尼 | Australia/Sydney | GMT+11 | 2026-11-01 16:30 | 0 |
| 东京 | Asia/Tokyo | GMT+9 | 2026-11-01 14:30 | 0 |
| 北京/上海 | Asia/Shanghai | GMT+8 | 2026-11-01 13:30 | 0 |
| 新德里 | Asia/Kolkata | GMT+5:30 | 2026-11-01 11:00 | 0 |
| 巴黎 | Europe/Paris | GMT+1 | 2026-11-01 06:30 | 0 |
| 伦敦 | Europe/London | GMT+0 | 2026-11-01 05:30 | 0 |
| 协调世界时 | UTC | GMT+0 | 2026-11-01 05:30 | 0 |
| 纽约 | America/New_York | GMT-4 | 2026-11-01 01:30 | 0 |
| 洛杉矶 | America/Los_Angeles | GMT-7 | 2026-10-31 22:30 | −1 |
| 纽埃 | Pacific/Niue | GMT-11 | 2026-10-31 18:30 | −1 |
两处细节值得留意。第一，纽约此刻显示 GMT-4 而不是 GMT-5：因为参考时刻 05:30 UTC 落在当地 11 月 1 日 06:00 UTC 的拨慢之前，那会儿还是夏令时。把参考时刻往后挪一小时，同一行的偏移就会变成 GMT-5。第二，新德里是 GMT+5:30，半小时间隔的偏移在换算成"相差几小时"时会出现 0.5 小时，用整数小时存储差值会把 30 分钟丢掉。
常见问题
为什么不能直接写 GMT+8，非要用 Asia/Shanghai？
因为 GMT+8 只是一句"恒定比 UTC 快 8 小时"的声明，里面没有任何规则。用 Asia/Shanghai 这个名字，程序才能在库里查到该地在历史上各个时段实际使用过的偏移和切换记录。对中国大陆来说两者目前结果相同，但同一份代码换成 America/New_York 就必须依赖规则才能算对——统一用 IANA 名可以让代码不必针对每个时区写特例。
夏令时切换那一天，当地钟表到底会发生什么？
两个方向都只有一小时长度的异常区间。拨快那天，有一段当地钟表时间根本不会出现（如 2026-03-08 纽约的 02:00～02:59）；拨慢那天，有一段当地钟表时间会重复出现（如 2026-11-01 纽约的 01:00～01:59）。前者会让"每天固定时刻执行"的任务那天少触发或错位，后者会让"当地字符串转绝对时刻"出现一对二的歧义。
同一个当地时刻为什么会对应两个 UTC 时刻？
因为在拨慢的那一小时里，当地字符串到绝对时刻的映射不再是一一对应。以纽约 2026-11-01 01:30 为例：第一次出现时偏移是 GMT-4，对应 05:30Z；拨回 01:00 之后它第二次出现，此时偏移是 GMT-5，对应 06:30Z。两者相差整整一小时。处理办法是别用当地字符串存事件，一律存 UTC 时刻。
基里巴斯和纽埃真的能差 25 小时吗？
能。基里巴斯使用的 Pacific/Kiritimati 是 UTC+14，纽埃使用的 Pacific/Niue 是 UTC−11，两者相差 25 小时。所以在同一瞬间，基里巴斯的日历日期一定比纽埃早一天。基里巴斯在 1995 年把这条线往东挪过，才让本国各岛处在同一天里，这也是 tzdata 里记录的历史事件之一。
为什么「日期偏移」这一列不能自己拿偏移量算？
理论上当地时刻 = UTC 时刻 + 偏移，日期也就跟着定了。但逐年累加会撞上闰年、二月天数、以及跨月跨年的进位，手算极容易错一天；更麻烦的是在 DST 切换的边界上，偏移本身在一个小时内是变化的。交给 Intl.DateTimeFormat 用同一套规则算出来，再直接比较当地日期和 UTC 日期，才不会有内部矛盾。
页面上显示的时区列表是谁提供的？
不是本页自带的清单，而是运行环境里的 ICU 数据。也就是说，浏览器或 Node 的 ICU 版本决定了 America/New_York 这类名字是否被认识、以及某年某日的偏移是多少。ICU 会随 IANA tzdata 更新，所以升级系统或浏览器后，将来年份的偏移结果可能会变——那是规则真的改了，不是计算出错。本页所有示例值都标注了对应年份 2026。
清空参考时刻以后会发生什么？
工具会切到实时模式，每秒刷新一次，用当前的绝对时刻重算所有城市。输入框里放一个具体时刻就是"冻结"在该瞬间。这样两种用法都保留了：想排期就冻结一个候选时刻慢慢看，想当钟用就清空它。
这个工具会不会记录我看了哪些城市？
不会。所有计算都在浏览器里由 Intl.DateTimeFormat 完成，没有任何网络请求，也没有写 localStorage。唯一的读取操作是获取你浏览器自带的时区名称（resolvedOptions().timeZone），这个值只用于在高亮那一行，不会离开本机。
相关工具
- Unix时间戳转换器：在秒级时间戳与可读日期之间互转，跨时区的事件建议统一用这种绝对刻度存储。
- 日期格式化转换器：按 ISO 8601 等格式输出日期字符串，注意带偏移量的写法才能无歧义地表达某一瞬间。
- 日期间隔天数计算器：算两个日期之间隔了多少个日历日，与本页的"同一瞬间在不同时区是否同一天"是两个问题。
- 日期加天数计算器：从某个日期往后推若干天，常用于算交付期和到期日。
- 工作日计算器：剔除周末与法定假日后的工作日数，跨时区协作时还要额外注意对方的公共假日。
- 农历公历转换：农历日期与公历日期的对应，节气与节日的推算依赖中国时区。
- 二十四节气查询：节气的准确时刻以天文计算为准，显示成本地时间时需要标明时区。
- 日期时间：查看全部日期时间工具。