この変換機の計算方法
入力した日付と時刻を、基準都市の壁掛け時計の時刻として受け取り、まずUTC(協定世界時)上の一つの瞬間に直します。そのうえで、同じ瞬間に 変換先の都市の時計が何時を指すかを求めます。各都市は、America/New_YorkやAsia/KolkataのようなIANAタイムゾーンIDに結びつけてあり、 ブラウザ内蔵のIntl.DateTimeFormatがIANAタイムゾーンデータベースを使って、その日付に適用されるUTCオフセットを返します。 オフセットは日付から決まるので、単に固定の時間数を足し引きするのではなく、その日にサマータイムかどうかまで反映した時差になります。
対象は25都市で、東アジア・南アジア・中東・ヨーロッパ・南米・北米(アラスカとハワイを含む)・オセアニアの主要な地域を押さえています。 すべての都市を網羅した一覧ではないので、目的の都市がなければ同じ時間帯の都市を選んでください。ワシントンD.C.はニューヨーク、バンクーバーはロサンゼルスと同じ時計です。
限界:結果はブラウザやOSが持つタイムゾーンデータに依存します。最近ルールが変わった国で端末が更新されていないと、古いルールで表示されることがあります。 遠い将来の日付は、現在のルールが続くという前提の計算です。航空券・契約・申込期限・試験などの重要な予定は、必ず発行元が示す現地時刻で確認してください。
UTC・オフセット・時差が生まれる理由
地球は約24時間で360度自転するので、経度が15度ずれるごとに太陽時はおよそ1時間ずれます。町ごとに別々の時刻を使うと不便なため、世界は標準時のゾーンに分けられ、 多くはUTCからのオフセットで定義されています。かつての基準だったグリニッジ標準時(GMT)に代わり、現在は原子時計に基づくUTCが民間の時刻の基礎です。日常ではほぼ同じ値として扱われますが、 イギリスは冬にGMT、夏にUTC+1の夏時間を使います。UTC-5は協定世界時より5時間遅く、UTC+9は9時間進んでいることを表します。実際に使われているオフセットはUTC-12からUTC+14までです。
オフセットが整数の時間とは限りません。この一覧で端数のあるオフセットを持つ都市は、ニューデリー (UTC+5:30)です。世界にはネパール(UTC+5:45)のように45分刻みの例もあります。 変換は分単位で計算するので、こうした時差も正しく出ます。後述の1月の例では、ニューヨークが9:00のときニューデリーは19:30です。
25都市のUTCオフセット(ビルド時に計算)
次の表は、このページを生成したときに、ビルド環境にあるタイムゾーンデータから計算した値で、手入力した数字はありません。2026年1月15日と7月15日のオフセットを比べています。 二つの値が異なる都市は、その年にサマータイムを実施しています。25都市のうち12都市が実施し、13都市は実施していません。右端の列は、2026年にその都市の オフセットが切り替わる瞬間を、切り替え直後の現地の日付・時刻で示したものです。これはデータからの計算結果であり、公式の発表ではありません。公式の日付は変更されることがあるため、 必要なときは各国政府の案内で確認してください。
| 都市 | IANAタイムゾーン | 1月15日 | 7月15日 | 2026年にオフセットが変わる時点 |
|---|---|---|---|---|
| ソウル | Asia/Seoul | UTC+9 | UTC+9 | なし |
| 東京 | Asia/Tokyo | UTC+9 | UTC+9 | なし |
| 北京 | Asia/Shanghai | UTC+8 | UTC+8 | なし |
| シンガポール | Asia/Singapore | UTC+8 | UTC+8 | なし |
| バンコク | Asia/Bangkok | UTC+7 | UTC+7 | なし |
| ジャカルタ | Asia/Jakarta | UTC+7 | UTC+7 | なし |
| ニューデリー | Asia/Kolkata | UTC+5:30 | UTC+5:30 | なし |
| ドバイ | Asia/Dubai | UTC+4 | UTC+4 | なし |
| モスクワ | Europe/Moscow | UTC+3 | UTC+3 | なし |
| イスタンブール | Europe/Istanbul | UTC+3 | UTC+3 | なし |
| カイロ | Africa/Cairo | UTC+2 | UTC+3 | 2026-04-24 01:00 (UTC+2 → UTC+3); 2026-10-29 23:00 (UTC+3 → UTC+2) |
| パリ | Europe/Paris | UTC+1 | UTC+2 | 2026-03-29 03:00 (UTC+1 → UTC+2); 2026-10-25 02:00 (UTC+2 → UTC+1) |
| ベルリン | Europe/Berlin | UTC+1 | UTC+2 | 2026-03-29 03:00 (UTC+1 → UTC+2); 2026-10-25 02:00 (UTC+2 → UTC+1) |
| ロンドン | Europe/London | UTC+0 | UTC+1 | 2026-03-29 02:00 (UTC+0 → UTC+1); 2026-10-25 01:00 (UTC+1 → UTC+0) |
| リスボン | Europe/Lisbon | UTC+0 | UTC+1 | 2026-03-29 02:00 (UTC+0 → UTC+1); 2026-10-25 01:00 (UTC+1 → UTC+0) |
| サンパウロ | America/Sao_Paulo | UTC-3 | UTC-3 | なし |
| ブエノスアイレス | America/Argentina/Buenos_Aires | UTC-3 | UTC-3 | なし |
| ニューヨーク | America/New_York | UTC-5 | UTC-4 | 2026-03-08 03:00 (UTC-5 → UTC-4); 2026-11-01 01:00 (UTC-4 → UTC-5) |
| シカゴ | America/Chicago | UTC-6 | UTC-5 | 2026-03-08 03:00 (UTC-6 → UTC-5); 2026-11-01 01:00 (UTC-5 → UTC-6) |
| デンバー | America/Denver | UTC-7 | UTC-6 | 2026-03-08 03:00 (UTC-7 → UTC-6); 2026-11-01 01:00 (UTC-6 → UTC-7) |
| ロサンゼルス | America/Los_Angeles | UTC-8 | UTC-7 | 2026-03-08 03:00 (UTC-8 → UTC-7); 2026-11-01 01:00 (UTC-7 → UTC-8) |
| アンカレジ | America/Anchorage | UTC-9 | UTC-8 | 2026-03-08 03:00 (UTC-9 → UTC-8); 2026-11-01 01:00 (UTC-8 → UTC-9) |
| ホノルル | Pacific/Honolulu | UTC-10 | UTC-10 | なし |
| オークランド | Pacific/Auckland | UTC+13 | UTC+12 | 2026-04-05 02:00 (UTC+13 → UTC+12); 2026-09-27 03:00 (UTC+12 → UTC+13) |
| シドニー | Australia/Sydney | UTC+11 | UTC+10 | 2026-04-05 02:00 (UTC+11 → UTC+10); 2026-10-04 03:00 (UTC+10 → UTC+11) |
サマータイムは地域ごとに違う
サマータイム(夏時間)は、暖かい季節に時計を進め、その後に戻す制度です。世界共通のルールはありません。アメリカとカナダの大部分、この一覧のヨーロッパの国々で実施されています。 南半球は12〜2月が夏なので、シドニーやオークランドは北半球の冬にサマータイムとなり、時計を動かす向きが逆になります。日本・中国・シンガポール・インド・タイ・インドネシア・アラブ首長国連邦など、 実施していない地域も多く、ハワイもその一つです。廃止したり時刻を固定したりした国もあり、上の表ではモスクワ、イスタンブール、サンパウロは2026年にオフセットの変化がありません。
実務で大切なのは、二つの都市の時差が一年中同じとは限らないことです。アメリカとヨーロッパは通常、別の週末に時計を切り替えるため、春と秋の短い期間はニューヨークとロンドンの時差が普段より1時間短くなります。 実際の切り替え時点は上の表で確認し、気になる日は変換機の日付欄で試してください。
変換機と同じコードで計算した例
例1: 真冬、2026年1月15日のニューヨーク9:00。ロンドンは2026-01-15 14:00 (UTC+0)、東京は2026-01-15 23:00 (UTC+9)、ニューデリーは2026-01-15 19:30 (UTC+5:30)、シドニーは2026-01-16 01:00 (UTC+11)です。シドニーは翌日になり、 ニューデリーは30分の端数が付くことに注目してください。
例2: 真夏、2026年7月15日のニューヨーク9:00。ロンドンは2026-07-15 14:00 (UTC+1)、東京は2026-07-15 22:00 (UTC+9)、ニューデリーは2026-07-15 18:30 (UTC+5:30)、シドニーは2026-07-15 23:00 (UTC+10)です。 冬の例とロンドンが違うのは、イギリスが夏時間だからです。シドニーが違うのは、ニューヨークがサマータイム、シドニーが標準時になっているからです。東京はサマータイムがないので、ニューヨークの側が変わっただけです。
例3: 2026年3月15日のニューヨーク9:00。このページのビルド時のデータでは、ロンドンは2026-03-15 13:00 (UTC+0)で、時差は4時間です(1月は5時間)。この時期はアメリカとヨーロッパの切り替えの タイミングがずれています。この時期に会議を組むときは、必ずその日付で試してください。
よくある間違い
- 一つの時差を丸暗記する:「ニューヨークはロンドンより5時間遅い」は一年の大半で正しくても、常にではありません。日付も一緒に確認してください。
- 国全体を一つの時間帯とみなす:アメリカ本土は4つ、ロシアはさらに多く、オーストラリアやカナダにも複数あります。シカゴは中部、デンバーは山岳部、ロサンゼルスは太平洋時間と、都市を正しく選びましょう。
- 大きな国は時間帯も多いと決めつける:中国は国全体で北京時間(UTC+8)の一つだけを使います。
- 切り替え当日を見落とす:春の切り替え日には存在しない1時間があり、ニューヨークの当日2:30のような時刻は飛ばされます。秋は同じ1時間が2回あります。存在しない時刻はエラーになり、重複する時刻はどちらか一方だけで計算されるので、前後の時刻を手で確認してください。
- 招待状に「午前10時」とだけ書く:受け取る側が自分の時間帯で読んでしまうことがあります。時間帯名かUTCオフセットを必ず添えましょう。
国をまたぐ予定のコツ
招待には必ず時間帯を書き、カレンダーアプリの時間帯欄を使えば、参加者それぞれの画面に現地時刻で表示されます。定例会議は切り替えの時期に注意が必要です。ニューヨーク9:00に固定した毎週の会議は、 春と秋の数週間、ロンドンのカレンダーで1時間ずれることがあります。締め切りは「UTCの23:59」のようにサマータイムの影響を受けない形で書くのが確実です。サーバーのログやデータベースは UTCで保存し、表示のときにだけ変換するのが基本です。航空便の出発・到着時刻は現地時刻で表示されるため、夜行便では日付が変わります。この変換機に日付を入れると、日付の変化も確認できます。
時刻の変換ではなく、イベントまでの日数を数えたいときはD-dayカウントダウンが向いています。ほかの都市の時刻を調べたいときは時間帯変換機、地球の自転がなぜ時差を生むのかは地球科学の豆知識で確認できます。
よくある質問
日付が変わる場合も表示されますか?
はい。変換結果が翌日や前日になる場合はその旨を表示し、全都市の表には各都市の現地の日付も並びます。
サマータイムは自動で反映されますか?
はい。入力した日付によって各都市のオフセットが決まるので、その日にサマータイムの都市は夏のオフセットで計算され、結果のチップに使った値が表示されます。
どのタイムゾーンデータベースを使っていますか?
ブラウザの標準Intl APIを通じて使うIANAタイムゾーンデータベースです。各都市はEurope/LondonやPacific/Aucklandのような識別子に対応しています。更新されていない古い端末では、古いルールのままの場合があります。
30分刻みの時差がある国はありますか?
あります。インドはUTC+5:30、ネパールはUTC+5:45、オーストラリアの一部はUTC+9:30です。この変換機は分単位で計算するので、こうしたオフセットにも対応します。
UTCとGMTは同じですか?
日常の予定では同じ値として扱われます。UTCは原子時計に基づく現在の標準、GMTは天文観測に由来する古い基準です。イギリスは冬にGMT、夏にUTC+1の夏時間を使います。