World clock / time zones
City-by-city clocks, conversion of a chosen moment and a helper for international meetings; zones and daylight saving always come from the browser’s own IANA time-zone data and every conversion happens in your browser, nothing uploaded.
多城市当前时间
时差一列是按同一瞬间的真实 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、也不写进网址，这样你在页面上留下的偏好痕迹为零。也正因为不经过服务器，它不受任何接口限流影响，断网后已打开的页面同样能用。
FAQ
Because the US and China start and end daylight saving on different dates. The US runs DST from the second Sunday of March to the first Sunday of November (EDT, UTC−4), during which New York is 12 hours behind Beijing; the rest of the year (EST, UTC−5) it is 13 hours behind. China has not observed DST since 1992 and stays at UTC+8 all year. The offsets on this page are subtracted from the real offset at this very moment, so they change with the seasons automatically instead of being hard-coded numbers.
India uses UTC+05:30 all year (no DST). Beijing is UTC+08:00, so the two cities differ by 2 hours 30 minutes - 11:30 in Beijing is exactly 09:00 in New Delhi. Nepal goes further with UTC+05:45, 2 hours 15 minutes behind Beijing. Any half-hour or 45-minute zone defeats whole-hour mental arithmetic - this page asks the browser's time-zone database directly, so the output is exact.
Every result gives the target city's local date and time, with a 'previous day / next day' tag after the date to flag the rollover. For example, Beijing 2026-01-01 09:00 corresponds to New York 2025-12-31 20:00 - the previous day; the same instant is 2025-12-31 17:00 in Los Angeles. Pay particular attention to this tag when scheduling meetings - 'tomorrow 10 a.m.' can land in your counterpart's today or day after tomorrow.
It depends on your browser's time-zone database version. DST rules come from the IANA time-zone data shipped with your browser; Chrome, Edge, Firefox and Safari update it with browser releases, so ad-hoc national changes (a year where DST starts early or is cancelled) need a browser update to catch up. For exact times in historical records, contracts or legal documents, rely on official announcements or an authoritative time-zone database; this page is for everyday conversion and meeting scheduling, not a legal time reference.
No. The city list lives only in a memory variable of the current page: refreshing returns you to the default cities; the page writes nothing to localStorage, no cookies, puts no cities in the URL, and sends no requests to any server (open the Network panel in developer tools and you will see zero requests for the whole page). All conversion uses built-in browser capabilities, so it keeps working offline.