Time Zone Converter
世界時計・日時のタイムゾーン変換
現在時刻を1秒ごとに更新しています。日時を入力すると、その日時を各タイムゾーンへ変換します。
Japan
JST (Tokyo)
Universal
UTC
USA
EST/EDT (New York)
UK
GMT/BST (London)
Time Zone Converterの使い方
選んだ都市の日時を一覧に並べ、時差と日付のズレを同時に確認できるツールです。基準日時を空にしておくと「今この瞬間」を1秒ごとに更新する世界時計として動き、日時を入力するとその日時（端末のタイムゾーンの時刻として解釈）を各都市の日時へ変換します。変換はブラウザ標準の Intl.DateTimeFormat に IANA タイムゾーン名（Asia/Tokyo など）を渡して行っており、夏時間（DST）の切り替えもブラウザ内蔵のタイムゾーンデータベースに従って自動で反映されます。外部サーバーとの通信は行いません。
基準日時を決める
現在時刻を見るだけなら基準日時は空のままにします。未来の会議や過去の出来事の時刻を換算したい場合は、基準日時の欄に日付と時刻を入力します。入力値は端末のタイムゾーン（日本なら JST）の時刻として扱われ、「現在時刻に戻す」で世界時計に戻ります。
タイムゾーンの追加と確認
プルダウンから都市を選び「追加」を押すと一覧の末尾に行が増えます。初期状態では JST・UTC・ニューヨーク・ロンドンの4行です。各行の大きな数字が現地時刻（24時間表記・秒まで）、その下が現地の日付と曜日で、海外の行では日付が前日や翌日になることがあるので日付も確認してください。
不要な行の削除
行にマウスを重ねると右端にゴミ箱アイコンが表示され、クリックでその都市を一覧から外せます。同じ都市を二重に追加することはできません。
主要都市のUTCオフセットと夏時間の切替日（2026年）
このツールで追加できる8つのタイムゾーンについて、標準時と夏時間のUTCオフセット、2026年に夏時間が適用される期間、JST（日本標準時）との時差をまとめました。切替日は Intl.DateTimeFormat が参照する IANA タイムゾーンデータベースの値で確認しています。
| タイムゾーン（IANA名） | 標準時 | 夏時間 | 2026年の夏時間期間 | JSTとの差 |
|---|---|---|---|---|
| 東京（Asia/Tokyo） | UTC+9（JST） | なし | ― | 0 |
| UTC | UTC±0 | なし | ― | −9時間 |
| ニューヨーク（America/New_York） | UTC−5（EST） | UTC−4（EDT） | 3月8日〜11月1日 | −14時間／夏 −13時間 |
| ロサンゼルス（America/Los_Angeles） | UTC−8（PST） | UTC−7（PDT） | 3月8日〜11月1日 | −17時間／夏 −16時間 |
| ロンドン（Europe/London） | UTC±0（GMT） | UTC+1（BST） | 3月29日〜10月25日 | −9時間／夏 −8時間 |
| パリ（Europe/Paris） | UTC+1（CET） | UTC+2（CEST） | 3月29日〜10月25日 | −8時間／夏 −7時間 |
| 上海（Asia/Shanghai） | UTC+8（CST） | なし | ― | −1時間 |
| シドニー（Australia/Sydney） | UTC+10（AEST） | UTC+11（AEDT） | 1月1日〜4月5日、10月4日〜12月31日 | +1時間／夏 +2時間 |
※ 切替日は現地時刻の日付です。米国は「3月第2日曜〜11月第1日曜」、イギリスと EU 加盟国は「3月最終日曜〜10月最終日曜」、オーストラリアのニューサウスウェールズ州は「10月第1日曜〜翌年4月第1日曜」というルールで毎年決まります。 日本では1948年から1951年まで夏時間が実施されましたが、1952年以降は実施されておらず、JST は年間を通じて UTC+9 で固定です。
各タイムゾーンの定義とその変更履歴はIANA Time Zone Databaseで公開されており、ブラウザはこのデータベース（を取り込んだ ICU）を使ってIntl.DateTimeFormatの変換を行います。このツールはその結果をそのまま表示しており、独自のオフセット表は持っていません。
UTC・JST・現地時刻の関係と ISO 8601 のオフセット表記
タイムゾーンをまたいだ時刻は、いったん UTC に直してからオフセットを足す、という1本の式で整理できます。システム間で日時を受け渡すときの標準的な書き方（ISO 8601 / RFC 3339）もあわせて確認しておくと、上の表の値をそのまま使えます。
たとえば 10:00 JST は、JST のオフセットが +9 なので 01:00 UTC です。 これに夏時間中のニューヨークのオフセット −4 を足すと 21:00 EDT（前日）、ロンドンの +1 を足すと 02:00 BST になります。 時差を直接引き算しても同じ結果になりますが、「片方だけ夏時間中」のケースでは UTC を経由したほうが間違えにくくなります。
ISO 8601（インターネット向けのプロファイルは RFC 3339）では、同じ瞬間を次のように書き表します。末尾の Z は UTC、+09:00 のような部分がオフセットです。
| 表記 | 意味 |
|---|---|
| 2026-07-01T10:00:00+09:00 | 日本時間（JST）の7月1日10時 |
| 2026-07-01T01:00:00Z | 同じ瞬間を UTC で表したもの |
| 2026-06-30T21:00:00-04:00 | 同じ瞬間をニューヨーク夏時間（EDT）で表したもの |
※ 「CST」は中国標準時（UTC+8）・米国中部標準時（UTC−6）・キューバ標準時（UTC−5）のいずれにも使われるなど、略称はタイムゾーンを一意に特定できません。 システム間で日時を渡すときは略称ではなく、上のようなオフセット付き表記か Asia/Tokyo のような IANA 名を使うのが確実です。 表記の仕様は RFC 3339 で参照できます。
実際の使用例
日本の朝10時（北半球の夏時間期間）を初期4行で見る
日本時間の端末で基準日時に 2026-07-01 10:00 を入力したときの、他の3行の表示です。ニューヨークは夏時間（EDT・UTC−4）なので前日の21時、ロンドンは夏時間（BST・UTC+1）なので同日の2時になります。
INPUT
基準日時: 2026-07-01T10:00（端末: Asia/Tokyo） JST (Tokyo): 2026/07/01(水) 10:00:00
OUTPUT
UTC: 2026/07/01(水) 01:00:00 EST/EDT (New York): 2026/06/30(火) 21:00:00 GMT/BST (London): 2026/07/01(水) 02:00:00
同じ朝10時でも1月は結果が変わる
2026/01/15(木) 10:00:00 JST の場合です。ニューヨーク（EST・UTC−5）とロンドン（GMT・UTC±0）はともに標準時に戻るため、7月より1時間早い時刻が表示されます。
INPUT
JST (Tokyo): 2026/01/15(木) 10:00:00
OUTPUT
UTC: 2026/01/15(木) 01:00:00 EST/EDT (New York): 2026/01/14(水) 20:00:00 GMT/BST (London): 2026/01/15(木) 01:00:00
ロサンゼルス・パリ・シドニーを追加した場合
プルダウンから3都市を追加したときの表示です（2026/07/01(水) 10:00:00 JST の瞬間）。シドニーは南半球なので7月は標準時（AEST・UTC+10）で、JST より1時間進んだ時刻になります。
INPUT
JST (Tokyo): 2026/07/01(水) 10:00:00 追加: Los Angeles, Paris, Sydney
OUTPUT
PST/PDT (Los Angeles): 2026/06/30(火) 18:00:00 CET/CEST (Paris): 2026/07/01(水) 03:00:00 AEST/AEDT (Sydney): 2026/07/01(水) 11:00:00
よくある質問
過去や未来の特定の日時を入力して変換できますか？
できます。上部の「基準日時」に日付と時刻を入力すると、1秒ごとの更新が止まり、その日時を各タイムゾーンへ変換した結果が表示されます。入力値はお使いの端末のタイムゾーン（日本で使っていれば JST）の時刻として解釈されるので、「東京の7月1日10時はニューヨークで何時か」のように、端末の地域を起点にした換算に使ってください。海外の時刻を起点にしたい場合は、下の「主要都市のUTCオフセット表」で対象日の時差を確認し、その分を足し引きした日本時間を入力します。「現在時刻に戻す」を押すか入力欄を空にすると世界時計に戻ります。
夏時間（サマータイム）は自動で反映されますか？
はい。変換には Intl.DateTimeFormat を使っており、夏時間の開始・終了日はブラウザ（とその元になる OS や ICU）が持つ IANA タイムゾーンデータベースに従います。ツール側に独自の切替ルール表は持っていません。2026年の場合、ニューヨークとロサンゼルスは3月8日〜11月1日、ロンドンとパリは3月29日〜10月25日、シドニーは4月5日まで、および10月4日以降が夏時間として扱われます。各国が制度を変更した場合は、ブラウザや OS の更新によって新しいルールが反映されます。
一覧にない都市（シンガポールやインドなど）を追加できますか？
現在のバージョンではプルダウンにある8つのタイムゾーン（東京・UTC・ニューヨーク・ロサンゼルス・ロンドン・パリ・上海・シドニー）だけを追加できます。IANA 名を自由に入力する欄はありません。上海は UTC+8 で夏時間がないため、同じ UTC+8 のシンガポール・香港・台北・パースの時刻は上海の行で代用できます。インド（UTC+5:30）のように30分単位のオフセットを持つ地域は代用できる行がないので、UTC の行に5時間30分を足して読み替えてください。
「EST/EDT (New York)」のように名前が2つ並んでいるのはなぜですか？
夏時間のある地域では、標準時と夏時間で略称が変わるためです。ニューヨークは標準時が EST（UTC−5）、夏時間が EDT（UTC−4）、ロンドンは標準時が GMT（UTC±0）、夏時間が BST（UTC+1）です。行の名前は固定表示で、今どちらの略称が有効かは表示しません。どちらが適用中かは、その行と UTC の行との差を見れば判断できます。
表示される時刻はどのくらい正確ですか？
世界時計として使う場合は端末の時計をそのまま基準にするため、精度は端末の時計次第です。端末の時計が数分ずれていれば、すべての行が同じだけずれます。NTP などの時刻同期を有効にした端末であれば、通常は秒単位で現地時刻と一致します。基準日時を入力した場合は端末の時計に依存せず、入力した日時をそのまま変換します。うるう秒は表示に反映されません。
追加した都市や表示内容はどこかに送信・保存されますか？
いいえ。このページは追加した都市の一覧と入力した基準日時をブラウザ上の状態として保持し、Intl.DateTimeFormat でブラウザ内で整形しているだけで、通信処理は含まれていません。追加した都市や基準日時はページを再読み込みすると初期状態（4行・現在時刻）に戻ります。
UTC と GMT は同じものですか？
日常の時刻表示では同じ「UTC±0」として扱って差し支えありませんが、定義は異なります。GMT はグリニッジ天文台の平均太陽時に由来する時刻、UTC は原子時計を基準にうるう秒で調整される国際標準です。このツールの「UTC」行は協定世界時、「GMT/BST (London)」行はイギリスの地域時刻で、ロンドンは夏時間中は UTC より1時間進みます。
役立つTips
時差は季節で1時間変わる
JST とニューヨークの時差は標準時で14時間、夏時間中は13時間、ロンドンは9時間と8時間です。定例会議の時刻を固定していると、3月と10〜11月の切替週に片方だけ1時間ずれるので、この時期は各行の日付・時刻を改めて確認してください。
相手側の日付が前日になっていないか確認
JST の午前中は、ニューヨークやロサンゼルスでは前日の夕方〜夜です。「7月1日の10時」を伝えるときは、相手側の日付（6月30日）も添えると誤解を避けられます。
南半球は夏時間の時期が逆
シドニーは10月〜4月が夏時間（UTC+11）、4月〜10月が標準時（UTC+10）で、北半球と逆です。日本の夏にはシドニーとの時差は1時間、日本の冬には2時間になります。
夏時間ルールはブラウザの更新で変わる
夏時間の切替日はブラウザ内蔵のデータベースに依存します。長期間更新していないブラウザや OS では、制度を変更した国の時刻が実際とずれることがあります。