タイムゾーン変換

日本時間と UTC、主要都市の時刻を一度に変換します。夏時間も自動で反映し、ISO 8601 の形でコピーできます。

として読む

「2026-09-20 18:00」「2026/9/20 18:00:00」のほか、「2026-09-20T09:00:00Z」「…+05:30」のようにずれ付きなら、そちらを優先して読みます。

･

ボタンを押すと、ここに結果が出ます

使い方とメモ

日本時間の「2026-09-20 18:00」を UTC にするなら、そのまま入れて「日本（JST）として読む」で変換。逆に UTC の日時は「UTC として読む」に切り替えるか、末尾に Z を付けます。
夏時間は日付ごとに自動で反映します。ニューヨークは 3〜11 月が UTC-4、それ以外が UTC-5 です。
「翌日」「前日」は、読んだゾーンの日付と比べたものです。深夜の予定を海外と調整するときの見落としを防ぎます。
ISO 8601 の列はそのまま API のパラメータやログに貼れる形です。UTC は Z、それ以外は +09:00 のようなずれ付きで出します。

UTC・オフセット・タイムゾーン

時刻の話でよく混ざる3つの言葉を整理しておきます。

UTC（協定世界時）: 世界の時刻の基準です。夏時間はありません。サーバーやデータベースに保存する時刻は、UTC にそろえておくと後で困りません。
オフセット: UTC からのずれです。日本は +09:00。2026-10-05T09:00:00+09:00 と 2026-10-05T00:00:00Z は同じ瞬間を表します（Z は UTC のこと）。
タイムゾーン: Asia/Tokyo や America/New_York のような地域の名前です。オフセットと違い、夏時間の切り替えや過去の制度変更まで含めた「その地域の時計の決まり」を表します。

ニューヨークのオフセットは、夏は -04:00、冬は -05:00 です。会議の予定のように「現地の何時」を残したいときは、オフセットではなくタイムゾーン名で持つ必要があるのはこのためです。

夏時間で時差が変わる

日本には夏時間がありませんが、相手の国にはあることが多く、時差が年に2回変わります。2026 年の切り替え日は次のとおりです。

地域	夏時間の開始	夏時間の終了	日本との時差
ニューヨーク	3月8日	11月1日	夏 13 時間・冬 14 時間
ロンドン	3月29日	10月25日	夏 8 時間・冬 9 時間
ベルリン・パリ	3月29日	10月25日	夏 7 時間・冬 8 時間
シドニー	10月4日	4月5日	夏 2 時間・冬 1 時間（日本より先）

アメリカとヨーロッパは切り替え日が違います。2026 年なら 3月8日〜29日と 10月25日〜11月1日は、ニューヨークとロンドンの時差がいつもの 5 時間ではなく 4 時間になります。毎週の定例会議が、この時期だけ1時間ずれることがあるので注意してください。南半球のシドニーは季節が逆なので、夏時間も 10 月から 4 月です。

存在しない時刻・2回ある時刻

夏時間が始まる日は時計が1時間進むため、存在しない時刻があります。ニューヨークの 2026年3月8日は、午前 2:00 になった瞬間に 3:00 になるので、2:30 という時刻はありません。逆に終わる日（11月1日）は 1:00〜1:59 が2回あります。

現地時刻で予定を組むバッチ処理や予約システムでは、この日に「実行されない」「2回実行される」が起こりえます。決まった時刻に動かす処理は、UTC で指定しておくのが安全です。

JST・CST のような略称に頼らない

タイムゾーンの略称は、同じ文字が別の地域を指すことがあります。CST はアメリカ中部標準時のほかに中国標準時の意味でも使われ、IST はインド・アイルランド・イスラエルのいずれにも使われます。

表示する側でも略称は安定しません。ブラウザに東京の略称を聞くと、日本語の設定では JST と返りますが、英語（アメリカ）の設定では GMT+9 と返ります。このツールが略称を出さず UTC+09:00 の形でそろえているのは、そのためです。人に伝える時刻も、略称ではなく「日本時間」「UTC+9」と書くと誤解がありません。

ISO 8601 で書いておく

API やログで時刻をやりとりするときは、2026-10-05T09:00:00+09:00 のように日付・時刻・オフセットをそろえた ISO 8601 の形が確実です。10/05/2026 のような書き方は、月と日のどちらが先かが国によって違うため、読み違いの元になります。オフセットのない 2026-10-05 09:00 も、どこの 9 時なのかが分かりません。