세계시계·시간대 변환

UTC 偏移只是「某一瞬间」的属性，不是城市的固定标签。每个地方的时间都可以写成「UTC + 一个偏移量」，但这个偏移量会随季节变化：伦敦冬令时是 UTC+0、夏令时（BST）是 UTC+1；纽约冬令时 UTC−5、夏令时（EDT）是 UTC−4。所以「纽约比北京晚 13 小时」这句话只在冬天成立，到了 3 月第二个周日之后的夏天就变成晚 12 小时。换算时必须先确定「是哪一瞬间」，再问「这一瞬间各地各自的偏移是多少」——顺序反了就会在夏令时切换的一两周里差一小时。

夏令时（DST）到底是什么。它是部分国家为了多在白天利用日照，在春季把钟表往前拨一小时（少睡一小时）、秋季再拨回来（多睡一小时）的制度。关键在于：切换日期由各国自己决定，年年可能变，而且不是所有国家都有。中国在 1986~1991 年实行过夏令时（那几年夏天的偏移是 UTC+9，所以 1990 年 9 月的上海比现在的北京时间还早一小时），1992 年起取消；俄罗斯 2011 年一度永久夏令时、2014 年又改回来；欧盟、美国、澳大利亚、巴西、智利、埃及的规则这些年都调整过。任何把偏移写死的表格都必然过期，正确做法是用系统自带的时区数据库（IANA tzdata）查表——本页就是这么做的。

为什么会有「半小时」「45 分钟」的时区。时区本来就不要求整小时：印度用 UTC+05:30、斯里兰卡 +05:30、尼泊尔 +05:45、缅甸 +06:30、伊朗 +03:30、阿富汗 +04:30、澳大利亚中部 +09:30、纽芬兰 −03:30、查塔姆群岛 +12:45。它们大多是历史上按本国经度或铁路时刻自行确定，之后为了与主要贸易伙伴对齐只调整了半小时。这类时区是「±N 小时」式手工换算最直接的翻车点：把新德里的 09:00 当成 UTC+5 来算，得到的就会是 04:00 而不是 03:30，越南、缅甸、尼泊尔同理。

怎么约跨国会议才不吵到对方。别只盯着「我这边几点方便」，而要同时看对方的工作时段。经验规则是：① 先把候选时刻换算成每个参会城市的当地时间和星期，确认没有落在 22:00~07:00 这种休息区间；② 尽量让所有关键决策人都落在 09:00~18:00，若做不到，优先牺牲非决策人的时区；③ 注意跨日陷阱——北京时间周一上午 10:00 是洛杉矶的周日傍晚 18:00（冬令时 18:00、夏令时 19:00），对方其实在休息日；④ 尽量避开对方夏令时切换的那两天（切换当天容易出现「会议时间差一小时」的沟通误差）；⑤ 会议邀请里务必写明时区名（如 Asia/Shanghai）而不是只写「上午 10 点」。本页的「会议时间助手」就是按这个思路，把同一个瞬间在各城市的当地时间和是否落在 09:00~18:00 一次列出来。

为什么不上传到服务器。时区换算不需要任何后端能力：浏览器本身就带着完整的 IANA 时区数据库（这也是它能正确显示你系统时间的原因），一个 Intl.DateTimeFormat 调用就能取出任意时区下的年月日时分秒。所以本页把全部计算放在你的设备上执行，输入的时刻、你添加的城市列表都不会离开浏览器（打开开发者工具的 Network 面板可以看到整页没有任何提交请求）。城市列表只存在内存里，刷新即失效，不写 localStorage、不写 cookie、也不写进网址，这样你在页面上留下的偏好痕迹为零。也正因为不经过服务器，它不受任何接口限流影响，断网后已打开的页面同样能用。