世界時計・時差変換
複数都市の時刻対照、指定時刻のタイムゾーン変換、国際会議の時間アシスト。タイムゾーンと夏時間はブラウザが持つ 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 月第 2 日曜から 11 月第 1 日曜まで夏令時（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 分の差です。30 分・45 分のタイムゾーンでは時間単位の暗算が通用しないため、本ページはブラウザのタイムゾーンデータベースに直接尋ねており、出力は正確です。
換算結果は対象都市の現地の日付と時刻を同時に表示し、日付の後ろに「前日 / 翌日」の注記を付けて日跨ぎを案内します。例えば北京時間 2026-01-01 09:00 はニューヨーク 2025-12-31 20:00 に対応し、ニューヨークは前日です。同じ瞬間のロサンゼルスは 2025-12-31 17:00。会議の約束ではこの注記に特に注意してください——「明日午前 10 時」が相手の側では今日や明後日に当たる可能性があります。
お使いのブラウザのタイムゾーンデータベースのバージョンによります。夏令時ルールは夏令時ルールはブラウザに内蔵の IANA タイムゾーンデータ由来です。Chrome、Edge、Firefox、Safari はいずれもブラウザ更新伴着で更新され、各国の臨時のルール変更（ある年に夏令時が前倒しや中止になった等）はブラウザバージョンが追いつくのを待つ必要があります。そのため歴史文書、契約書、法務文書に関わる正確な時刻は、公式発表または権威あるタイムゾーンデータベースを基準としてください。本ページは日常の換算や会議の約束向けで、法的な計時の根拠にはなりません。
されません。都市リストは現在のページのメモリ変数にのみ保存され、リロードするとデフォルト都市に戻ります。ページは localStorage に書き込まず、cookie も書かず、都市を URL に入れず、サーバーへ一切のリクエストも送りません（開発者ツールの Network パネルを開くとページ全体でリクエストゼロが確認できます）。すべてのタイムゾーン換算はブラウザ内蔵機能を使うため、ネット切断中でも使い続けられます。