🕒 タイムゾーン変換・世界時計
指定した日時を複数のタイムゾーン (IANA 400+ から選択) に同時変換。デフォルトで東京・NY・LA・ロンドン・パリ・シドニー・ムンバイ・サンパウロの 8 都市を表示。DST (サマータイム) を自動考慮、UTC オフセット表示、リアルタイム自動更新。
🔒 プライバシーについて
- ・すべての変換はブラウザ内 (JavaScript の Intl.DateTimeFormat) で完結します
- ・入力した日時はサーバーに送信されません
| 都市 / タイムゾーン | 日付 | 時刻 | UTC オフセット | DST |
|---|
📖 つまずきやすいポイント
IANA タイムゾーン (400 以上) を選んで世界時計を並べ、指定した日時を各都市の現地時刻に変換します。DST は Intl.DateTimeFormat が自動で考慮し、処理はブラウザ内で完結します。表示されている時刻は正確ですが、それを「予定」として保存する段階で壊れます — タイムゾーンは地域の属性であって、固定のオフセットではありません。この違いが、以下のすべての原因です。
| ケース | 何が起きるか | どうする |
|---|---|---|
| 定例会議が年に 2 回、1 時間ずれる | DST の切り替え日は国ごとに違います。米国は 3 月第 2 日曜から 11 月第 1 日曜、EU は 3 月最終日曜から 10 月最終日曜です。この差のせいで、3 月中旬から下旬と 10 月下旬から 11 月上旬は、ニューヨークとロンドンの時差が普段の 5 時間ではなく 4 時間になります — 年に 2 回、数週間だけ現れる「ずれ期間」です。日本は DST が無いので、日本側の時刻を固定すると相手側が動き、相手側を固定すると日本側が動きます。南半球はさらに逆で、オーストラリアは 10 月に始まり 4 月に終わります。 | 会議の案内には、両方の現地時刻を書いてください — 「東京 10:00 / ニューヨーク 21:00 (前日)」のように併記すれば、ずれ期間でも相手が気付けます。カレンダーの招待を使う場合は、必ずタイムゾーン付きで送ってください — 主要なカレンダーは IANA 名で予定を保持するので、DST の切り替えを自動で追随します。やってはいけないのは、オフセットで固定することです — 「UTC+9 の 10 時」と記録すると、相手のカレンダーでは DST のたびに動きます。定例会議は、切り替え日の直後に一度だけ「今週も同じ時刻で合っていますか」と確認する習慣をつけると、事故がほぼ無くなります。 |
| 時差が整数時間だと思い込んでいる | 時差には 30 分刻みと 45 分刻みの地域があります。インドは +05:30、ネパールは +05:45、イランは +03:30、ニューファンドランドは -03:30、そしてニュージーランドのチャタム諸島は +12:45 です。「時差 = 整数」という前提でコードを書くと、これらの地域でだけ静かに 30 分ずれます — 一覧に出てこない地域なので、テストでも気付きません。DST の幅も 1 時間とは限らず、オーストラリアのロードハウ島は30 分だけ進みます。 |
オフセットは分単位で保持してください — +9 ではなく +540 です。UI に表示するときも、小数で書かないでください (+5.5 は +05:30 と書くべきで、+5.75 は誤解を招きます)。そもそも、オフセットを自分で計算しないのがいちばん確実です — Intl.DateTimeFormat や各言語の標準の日時ライブラリに IANA タイムゾーン名を渡せば、30 分刻みも DST も、規則の変更もすべて処理してくれます。タイムゾーンの計算を自作したくなったら、それは間違いの兆候です — 例外が多すぎて、正しく書ける人はほとんどいません。 |
| タイムゾーンの略称を使って通じない | 3 文字の略称は一意ではありません。CST は米国中部標準時 (UTC-6)・中国標準時 (UTC+8)・キューバ標準時 (UTC-5) の 3 つを指しえます。IST もインド (UTC+5:30)・アイルランド (UTC+1)・イスラエル (UTC+2) のいずれかです。しかも略称は DST で変わります — 米国東部は冬が EST、夏が EDT なので、「EST の 9 時」と書かれた予定が夏の日付を指していたら、それは矛盾しています。国際的なやり取りで略称を使うと、相手が別の時刻だと解釈しても、どちらも間違っていません。 |
保存と通信には IANA 名 (Asia/Tokyo・America/New_York) を使ってください — これは一意で、DST の規則も歴史的な変更も含んでいます。略称は人間に見せる表示にだけ使い、その場合も必ず都市名を添えてください (「東京時間 (JST)」)。文章で書くときは、「日本時間 10 月 5 日 10:00 (UTC+9)」のように、地域・日付・時刻・オフセットを全部書くのが最も誤解が少ないです。相手がどのタイムゾーンにいるか分からない場合は、UTC で書いてください — 誰にとっても等距離で、変換の必要は生じますが、誤解は生じません。 |
タイムゾーンのデータベース (tzdata) は年に数回更新されます。各国は現在も夏時間の導入・廃止・期間の変更を続けており、2022 年にメキシコがほぼ全土で夏時間を廃止し、ヨルダンとシリアは通年で夏時間に固定し、EU は廃止を議論し続けています。つまり「タイムゾーンの規則」はコードではなくデータであり、そのデータは古くなります — コンテナイメージや OS のバージョンを固定していると、ある日を境に、その地域の時刻だけが 1 時間ずれ始めます。ベースイメージの更新は、セキュリティだけでなくこの理由でも必要です。運用の原則としては — 過去に起きたことは「瞬間」なので UTC で保存し、未来の予定は「約束」なので IANA タイムゾーン名 + ローカル時刻で保存してください。ログのタイムスタンプを IANA 名で持つ意味はありませんし、逆に来年の会議を UTC の瞬間で保存すると、法改正があった時点で現地の 10 時ではなくなります。
📖 使い方
-
1
モードを選択「現在時刻」モードでは世界時計が 1 秒ごとに更新されます。「指定日時を変換」モードでは入力した日時を各都市の現地時刻に変換します。
-
2
都市を追加・削除IANA タイムゾーン (400+) から選択して都市を追加できます。各行の × ボタンで削除、デフォルトに戻すボタンで初期 8 都市に戻ります。
-
3
DST と UTC オフセットを確認各行に現在の UTC オフセットと DST (サマータイム) 適用中かどうかが表示されます。会議調整・サーバーログ対応に便利です。
❓ よくある質問
IANA タイムゾーンとは何ですか?
DST (サマータイム) は自動で考慮されますか?
時刻はサーバーに送信されますか?
🔗 関連ツール
🐛 このツールで問題が発生しましたか？
完全無料・登録不要。再現手順だけでも結構です。届いたご報告は運営者に直接届き、修正の参考にします。
ご報告ありがとうございます！
運営者に届きました。改善の参考にさせていただきます。