タイムゾーン変換器

例：イギリスの切替週に東京 10 時はロンドンで何時か

イギリスはサマータイムを 10 月の最終日曜日に終えます（2026 年は 10 月 25 日、IANA europe ファイルの Rule EU）。日本は現在サマータイムを実施していないので、東京とロンドンの時差はこの日を境に 8 時間から 9 時間に広がります。ソースを Asia/Tokyo、対象に Europe/London を入れた結果です。

日本時間の朝 10 時に設定しているロンドンとの定例会議は、切替前は現地の深夜 2 時、切替後は深夜 1 時になります。ロンドンの行に BST や GMT の略称は出ません（理由は「制限事項」を参照）。オフセットの UTC+01:00 と UTC+00:00 で見分けてください。

1948〜1951 年の日本のサマータイム

日本にもサマータイム（夏時刻）があった時期があります。1948 年の夏時刻法（法律第二十九号）は、夏の期間は「中央標準時より一時間進めた時刻」を用いると定めていました。IANA の asia ファイルは 1948〜1951 年の規則（Japan）を収録していて、ツールは過去の日付にこの規則を当てはめます。

• ソースも対象も Asia/Tokyo：1950-07-01 10:00:00, UTC+10:00
• 対象が UTC：1950-07-01 00:00:00, UTC+00:00

1950 年は 5 月の第一土曜日の 24 時（5 月 7 日 0 時）に時計を 1 時間進めたので、5 月 7 日の 0 時台は存在しません。1950-05-07 00:30 を入力すると、ツールは 1 時間進んだ 1 時 30 分として読みます。

1950-05-07 01:30:00, UTC+10:00

昔の記録の時刻を UTC に直すとき、日本時間から一律に 9 時間引くとこの期間だけ 1 時間ずれます。

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

サマータイム開始時に飛ばされる 1 時間は存在せず、終了時に戻される 1 時間は 2 回あります。ツールの読み方は RFC 5545（iCalendar）3.3.5 節と同じです。存在しない時刻は飛ばされる前の UTC オフセットで解釈するので 1 時間進み、2 回ある時刻は 1 回目を採ります。たとえばニューヨークの 2026-11-01 01:30 は 2 回あり、ツールは 1 回目（EDT）を採ります。日本時間に直すと次のとおりです。

2026-11-01 14:30:00, UTC+09:00

2 回目の 01:30（EST）を指したいときは、ソースを UTC にして 2026-11-01 06:30 を入力します。

都市名の入力

「タイムゾーンを追加」と「ソースタイムゾーン」が受け付けるのは英語の都市名、UTC、IANA 名です。tokyo は Asia/Tokyo になりますが、「東京」と入力すると「未知のタイムゾーンです。都市名か IANA 名を入力してください。」と表示されます。osaka のように IANA 名にない都市も見つからないので、日本国内はすべて Asia/Tokyo を使います。大文字と小文字は区別しません。名前の一部だけでも、3 文字以上で、都市名のどれかの単語の先頭に当たり、一つのゾーンにしか当てはまらなければ見つかります（york で America/New_York）。san のように San_Juan や Santiago など複数に当てはまる入力は受け付けません。略称も受け付けません（JST、jst も同じ。EST や IST は複数の地域を指すためです）。

IANA 識別子が必要な理由

PST や CST、IST といった略称はあいまいです。CST 一つでも北米中部標準時、中国標準時、キューバ標準時のどれにもなり得ます。IANA タイムゾーンデータベースは「大陸/都市」（例: America/Chicago、Asia/Shanghai、America/Havana）で各地域を区別し、過去から現在までのオフセットと DST 規則を収めています。

本ツールの計算はすべて IANA 識別子で行います。行に並ぶ略称は読むための補助で、計算には使いません。

サマータイムと 7 日プレビュー

ツールは対象ゾーンで基準時刻の前後 7 日以内に UTC オフセットが変わるかを調べ、基準日と切替日がそのゾーンの暦で何日離れているかを数えます。その行には「n日後にサマータイム切替」または「n日前にサマータイム切替済み」、切替が基準日と同じ日なら「本日サマータイム切替」または「本日サマータイム切替済み」と出て、同じ会議時刻でも切替の前後で換算結果が変わることを知らせます。上の例では、ロンドンの切替は 10 月 25 日で、基準の 10 月 27 日とは 2 日離れているので「2日前」です。

その年にサマータイムを実施していないゾーン（Asia/Tokyo、Asia/Shanghai、Australia/Brisbane など）には「サマータイムなし」と出ます。判定は基準年の 1 月 15 日と 7 月 15 日のオフセットの比較なので、基準時刻を 1950 年にすると Asia/Tokyo にもこのバッジは出ません。1 月と 7 月のオフセットが同じでも前後 7 日以内に変化があるゾーンには、切替までの日数が出ます（例：Africa/Casablanca はラマダンに合わせて 2026-02-15 に UTC+01:00 から UTC+00:00 になります）。

共有リンクの仕組み

URL の # 以降に 3 つのパラメータが入ります。t が基準時刻、s がソース、z がカンマ区切りの対象タイムゾーンです。このパラメータは「リンクを共有」を押したときだけでなく、変更のたびにアドレスバーで更新されます。リンクを開いた側のブラウザがこの値を読んで対照表を作り直します。

プライバシーとオフライン

換算はブラウザ内の Intl.DateTimeFormat で行い、入力した時刻やタイムゾーンをツールが送信することはありません。ソースと対象の一覧はこのブラウザのローカルストレージに残ります。基準時刻は残りませんが、ソースや対象と一緒にアドレスバーの # 以降に書かれ、ブラウザの履歴に残ります。RFC 9110 7.1 節のとおり、リクエストの対象 URI には # 以降が含まれないので、共有リンクの値はページの読み込みでサーバーに送られません。ページを開いたあとは圏外でも換算を続けられますが、オフライン用のキャッシュはないため、閉じたページを開き直すには通信が必要です。

制限事項

• 略称はブラウザの英語（カナダ）のロケールデータから取るため、北米のゾーン（EST、PDT、AKST など）にしかありません。日本の行に JST は出ず、UTC オフセットだけが出ます。
• 検索候補は Intl.supportedValuesOf(‘timeZone’) の一覧で、1 ゾーンにつき 1 つの名前しか載らず、ブラウザのエンジンによって違います。Chrome は Asia/Kolkata、Europe/Kyiv ではなく Asia/Calcutta、Europe/Kiev を載せ、UTC は載せません。どれも入力すれば使えます。
• タイムゾーンデータはブラウザが持っているものです。各国が急に規則を変えた場合、ブラウザが更新されるまで未来の日付の結果がずれることがあります。
• 基準時刻に秒があれば秒も保ちます。勤務時間の一覧表や会議の候補を並べる表示はありません。
• Unix タイムスタンプの変換はタイムスタンプ変換器を使ってください。