世界时间 / 时区换算
多城市当前时间对照、指定时刻的跨时区换算、跨国会议时间助手；时区与夏令时一律取浏览器自带的 IANA 时区数据，所有换算都在你的浏览器里完成，不上传
多城市当前时间
时差一列是按同一瞬间的真实 UTC 偏移相减算出来的，所以夏令时生效期间它会自动变大或变小一小时（例如伦敦夏天比北京晚 7 小时、冬天晚 8 小时）。
关于精度与隐私（先把边界说清楚）
- 夏令时规则来自浏览器自带的时区数据库（IANA tzdata，Chrome / Edge / Firefox / Safari 随版本更新）。历史久远或未来年份的规则可能与你所在系统的版本有差异——例如某国哪一年开始、哪一年取消夏令时，或者某年临时调整过切换日期，不同浏览器版本给出的结果可能相差一小时；涉及历史档案、合同与法定时间，请以官方公告为准。
- 不能用「本地时间 ± N 小时」手工换算。夏令时会让同一个城市的偏移一年里变两次，印度是 +05:30、尼泊尔是 +05:45、部分太平洋岛国是 +12:45——只要手工按整小时加减，这些都会算错。本页一律把时刻交给
Intl.DateTimeFormat与 IANA 时区名去格式化。 - 所有换算都在你的浏览器里完成，不上传。本页不发送任何网络请求，你输入的城市列表只存在当前页面的内存里：刷新页面即失效，不写 localStorage、不写 cookie、不写网址、也不打印到控制台。
时区换算为什么不能自己加减小时
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、也不写进网址，这样你在页面上留下的偏好痕迹为零。也正因为不经过服务器，它不受任何接口限流影响，断网后已打开的页面同样能用。
常见问题
因为美国与中国的夏令时起止时间不同。美国 3 月第二个周日到 11 月第一个周日实行夏令时（EDT，UTC−4），这段时间纽约比北京晚 12 小时；其余时间（EST，UTC−5）晚 13 小时。而中国自 1992 年起不再实行夏令时，全年固定 UTC+8。本页的时差是按「当前这一瞬间」的真实偏移相减得出的，所以它会随季节自动变化，而不是一个写死的数字。
印度全年使用 UTC+05:30（没有夏令时）。北京是 UTC+08:00，两地相差 2 小时 30 分，所以北京 11:30 正好是新德里 09:00。尼泊尔更进一步，用 UTC+05:45，与北京相差 2 小时 15 分。凡是半小时或 45 分钟的时区，都不能用整小时加减去估算——本页直接问浏览器的时区数据库，输出自然是准确的。
换算结果会同时给出目标城市的当地日期与时间，并在日期后面标注「前一日 / 次日」，用来提示跨日。例如北京时间 2026-01-01 09:00 对应纽约 2025-12-31 20:00，纽约就是前一日；同一时刻在洛杉矶是 2025-12-31 17:00。约会议时尤其要留意这个标注——「明天上午十点」在不同时区可能落在对方的今天或后天。
取决于你浏览器的时区数据库版本。夏令时规则来自浏览器自带的 IANA 时区数据，Chrome、Edge、Firefox、Safari 随浏览器更新，各国临时调整规则（例如某年提前或取消夏令时）需要等浏览器版本跟上。因此历史文件、合同、法律文书中涉及的精确时间，请以官方公告或权威时区数据库为准；本页适合日常换算与约会议，不承担法律计时依据。
不会。城市列表只保存在当前页面的内存变量里，刷新页面即回到默认城市；页面不写 localStorage、不写 cookie、不把城市写进网址，也不向服务器发送任何请求（打开开发者工具 Network 面板可以看到整页零请求）。所有时区换算用的是浏览器内置能力，因此断网也能继续用。