東京の10時は、ニューヨークでは何時なのか。 夏と冬でずれる時差を、毎回頭の中で足し引きするのがつらい。 日付が前日にずれていないかも不安。 基準の日時と都市を選ぶだけで、主要12都市の現地時刻・UTCオフセット・夏時間の有無・日付のずれが一覧で出ます。
使い方
- 「基準日時」を入れ、「基準タイムゾーン」で、その時刻がどの都市のものかを選びます。
- 表に12都市の現地時刻が並びます。入力や選択を変えると、その場で更新されます。
- 「UTCオフセット」の欄に「（夏時間）」とあれば、その日時に夏時間が適用されています。
ここまでが基本の流れです。
- 「基準日との差」は、基準タイムゾーンの暦日と比べて「同日」「翌1日」「前1日」のどれかを示します。
- 「JST 10:00（今日）」「JST 21:00（今日）」「UTC 09:00（今日）」のボタンを押すと、その時刻が今日の日付で入ります。
なお、秒まで入力できます。表にも秒まで出ます。
仕組み・計算式
現地時刻とオフセットは、ブラウザの Intl.DateTimeFormat を通して、IANA Time Zone Database（tzdata）から取っています。夏時間の開始日や終了日、過去の制度改正もこのデータベースに入っています。
基準側の「壁時計の時刻」から UTC を求める手順は次のとおりです。
UTC = 壁時計の時刻 − その時点のオフセット
オフセットは UTC がわからないと決まらないので、いったん UTC とみなして仮のオフセットを取り、引き直す処理を最大3回繰り返しています。
「（夏時間）」の判定は、その年の1月15日と7月15日のオフセットのうち小さいほうを標準時とみなし、それより大きければ夏時間とする方法です。Intl が夏時間かどうかを直接返すわけではないため、このツール独自の判定です。
時刻の表記規則は ISO 8601 が定めています。UTC は世界時の基準で、日本標準時（JST）は UTC+9 です。
計算例
数字は、script.js の変換関数をそのまま node で実行して確かめた値です。
例1: 2026年9月10日 10:00（東京）
| 都市 | 現地時刻 | オフセット | 基準日との差 |
|---|---|---|---|
| UTC | 9/10 01:00 | +0:00 | 同日 |
| ロンドン | 9/10 02:00 | +1:00（夏時間） | 同日 |
| ニューヨーク | 9/9 21:00 | -4:00（夏時間） | 前1日 |
| ロサンゼルス | 9/9 18:00 | -7:00（夏時間） | 前1日 |
| ムンバイ | 9/10 06:30 | +5:30 | 同日 |
| シドニー | 9/10 11:00 | +10:00 | 同日 |
ムンバイが30分刻みなのは、Asia/Kolkata のオフセットが +5:30 だからです。シドニーはこの時期まだ夏時間に入っておらず、+10:00 のままでした。
例2: 同じ「東京10:00」を12月10日で見る
ロンドンは 01:00（+0:00）、ニューヨークは前日の 20:00（-5:00）になります。9月は ロンドン 02:00、ニューヨーク 21:00 でした。会議時刻は変わらないのに、夏時間の有無で現地時刻が1時間動くわけです。この月のシドニーは +11:00（夏時間）で、12:00 でした。
例3（境界値）: ニューヨーク 2026年3月8日 02:30
米国の春の切り替え日です。この日、時計は2:00から3:00へ進むので、02:30 は実在しません。この値を変換関数に通すと、ニューヨークの行は 03:30（-4:00、夏時間）になり、東京は同日の 16:30、ロサンゼルスは前日の 23:30 になりました。
秋の切り替え日（2026年11月1日）の 01:30 も同じ方法で確かめました。この時刻は2回あります。ニューヨークは夏時間側（-4:00）の 01:30 として扱われ、東京は 14:30 でした。
よくある間違い
1. 時差を「年中同じ」と思ってしまう
東京とニューヨークの時差は、夏は13時間、冬は14時間です。9月の10:00 が前日 21:00、12月の10:00 が前日 20:00 になることからも見えます。去年の会議の感覚で今年の日程を組むと、1時間ずれます。
確かめ方は、実際に開催する日付を入れることです。このツールでは日付を入れれば、その日の制度で変換されます。
2. 国ごとに夏時間の切り替え日が違うことを忘れる
米国は3月第2日曜、欧州は3月最終日曜に切り替わるため、その間の数週間は東京とニューヨーク、東京とロンドンの時差が普段と違います。切り替えの時期をまたぐ会議ほど、日付を入れて確認したほうが安全です。
3. 日付のずれを見落とす
東京の朝10時は、アメリカでは前日の夜です。時刻だけ見て「同日の21時」と読み違えると、招待メールの日付を間違えます。「基準日との差」の列で「前1日」と出ていないかを見てください。
4. 存在しない時刻・2回ある時刻を入力する
例3のとおり、切り替え日の深夜から早朝は、入力した時刻と表示される時刻が一致しないことがあります。業務で使う日時なら、切り替えの時刻帯は避けて決めるのが無難です。
よくある質問
Q. 表示されるタイムゾーン名（Asia/Tokyo など）は何ですか？
A. IANA Time Zone Database の識別子です。JST や EST のような略称と違い、地域ごとの夏時間の変遷を一意に指せるので、システム間の指定に使われます。
Q. EST と EDT のような略称は表示されますか？
A. 表示しません。このツールが出すのは、UTC からのオフセットと「（夏時間）」の有無です。正直なところ、略称よりオフセットのほうが誤読しにくいと感じています。
Q. UTC と GMT は同じですか？
A. 値としてはほぼ同じですが、UTC は協定世界時という時刻系、GMT はグリニッジ標準時という地域の標準時を指す名前です。このツールは UTC を基準にしています。
Q. 選べる都市を増やせますか？
A. できません。基準タイムゾーンの選択肢も、一覧に出る都市も、12都市に固定されています。
関連ツール
最終更新・根拠の確認日: 2026-10-08 · カテゴリ: 日付・時間