無料タイムゾーンコンバーター
世界中のタイムゾーン間で時刻を変換します。
使い方
- ドロップダウンから2つ以上のタイムゾーンを選択します。
- 任意のタイムゾーン列に日付と時刻を入力するか、「現在時刻を使用」をクリックします。
- UTCオフセットが表示された状態で、すべてのタイムゾーンで時刻が自動的に更新されます。
- 「+ タイムゾーンを追加」をクリックして、複数のタイムゾーンを一度に比較します。
よくある質問
UTCオフセットとは?
UTCオフセットは、タイムゾーンが協定世界時(UTC)からどれだけ進んでいる(正)または遅れている(負)時間数を示します。例えば、ESTはUTC−5です。
あるタイムゾーンに時刻を入力するとどうなりますか?
コンバーターは選択された他のすべてのタイムゾーンでの同等の時刻を自動的に計算して表示します。
夏時間は考慮されますか?
はい。コンバーターはブラウザのタイムゾーンデータベースを使用しており、サポートされている地域の夏時間ルールを含みます。
UTC、GMT、そしてIANA名を使うべき理由
UTC（協定世界時）は国際原子時を基準に定められた世界標準時で、定期的な閏秒調整が行われる。GMT（グリニッジ平均時）は厳密にはタイムゾーン（UTC+00:00）であり、歴史的にはロンドンのグリニッジ王立天文台に結びついている。この2つは日常的に互換的に使われるが、技術的にはUTCがすべての基準となる標準だ。
明確なタイムゾーン識別の標準はIANA タイムゾーンデータベース（TZDB）だ。1986年に米国国立衛生研究所のArthur David Olsonが作成し、現在はIANAが管理している。命名形式はRegion/City：America/New_York、Europe/Paris、Asia/Tokyo、Australia/Sydneyのように「地域/都市」で表される。都市名はそのゾーンで最大の都市か特徴的な地名だ。各国がDSTルールを変更するたびにTZDBは年数回更新され、現代のすべてのOS、プログラミング言語、主要なウェブブラウザは最新のコピーを同梱している。
このコンバーターはブラウザに組み込まれたIANAデータベースをJavaScriptのIntl.DateTimeFormat APIを通じて使用しているため、DST切り替え、地域ルールの変更、歴史的なエッジケースが自動的に正しく処理される。
タイムゾーン略語は曖昧だ
「CST」「IST」のような3文字略語は一見明確に見えるが、実際はそうではない：
- CSTは米国中部標準時（UTC−06:00）、中国標準時（UTC+08:00）、またはキューバ標準時（UTC−05:00）を意味する場合がある。
- ISTはインド標準時（UTC+05:30）、イスラエル標準時、またはアイルランド標準時を意味する場合がある。
- ESTは通常、米国東部標準時（UTC−05:00）を意味するが、オーストラリア東部標準時（UTC+10:00）も同じ略語を使う。
時刻を正確に伝える必要があるときは、IANAゾーン名（America/Chicago 対 Asia/Shanghai 対 Asia/Kolkata）を使うか、オフセットと都市名を両方含めること。このコンバーターは各列にIANAゾーン名をラベルとして表示するため、ミーティングの時刻が明確になる。
主要タイムゾーン一覧
| UTCオフセット | 通称 | 主要都市 |
|---|---|---|
| UTC−10:00 | HST | ホノルル（DSTなし） |
| UTC−08:00 / −07:00 | PST / PDT | ロサンゼルス、サンフランシスコ、バンクーバー、シアトル、ティフアナ |
| UTC−05:00 / −04:00 | EST / EDT | ニューヨーク、トロント、アトランタ、マイアミ、ボゴタ（DSTなし）、リマ |
| UTC−03:00 | BRT / ART | サンパウロ、ブエノスアイレス、サンティアゴ（変動あり） |
| UTC+00:00 / +01:00 | GMT / BST | ロンドン、リスボン、ダブリン、レイキャビク（DSTなし） |
| UTC+01:00 / +02:00 | CET / CEST | パリ、ベルリン、マドリード、ローマ、アムステルダム、ワルシャワ |
| UTC+03:00 | MSK / AST | モスクワ（DSTなし）、リヤド、ドーハ、ナイロビ |
| UTC+05:30 | IST | ムンバイ、ニューデリー、バンガロール、コロンボ（DSTなし、30分オフセット） |
| UTC+08:00 | CST / HKT / SGT | 北京、上海、香港、シンガポール、マニラ、パース |
| UTC+09:00 | JST / KST | 東京、ソウル（DSTなし） |
| UTC+10:00 / +11:00 | AEST / AEDT | シドニー、メルボルン、ブリスベン（QLD州はDSTなし） |
| UTC+12:00 / +13:00 | NZST / NZDT | オークランド、ウェリントン |
30分・15分単位のオフセット
タイムゾーンが必ずしもUTCから整数時間である必要はない。インド、スリランカ（UTC+05:30）、イラン（UTC+03:30 / +04:30）、アフガニスタン（UTC+04:30）、ミャンマー（UTC+06:30）はすべて30分単位のオフセットを使用している。ネパールはUTC+05:45で、ニュージーランドのチャタム諸島はUTC+12:45 / +13:45だ。こうした30分・15分単位のオフセットは主にソフトウェア開発者にとって重要で、古いシステムの多くは整数時間のオフセットを前提としており、インドやネパールの時刻でサイレントに誤動作することがある。IANAデータベースはこれらをすべて正しく処理しており、このコンバーターもそれを継承している。
夏時間（DST）
夏時間（DST）はウィリアム・ウィレットが1907年に発行したパンフレット「夏の昼光のむだ使い」で最初に提唱され、第一次世界大戦中の石炭節約のためドイツが1916年に正式に採用した。今日では地域によって内容が大きく異なる：
- アメリカ合衆国：DSTは3月第2日曜日から11月第1日曜日まで実施される（2005年エネルギー政策法）。ハワイ州とアリゾナ州の大部分は採用していない。
- 欧州連合：DSTは3月最終日曜日から10月最終日曜日まで実施される。EU議会は2019年にEU全体での季節時計変更廃止を決議したが、実施は無期限に延期されており、ほとんどの加盟国は依然としてDSTを実施している。
- DST非採用：アフリカの大部分、アジアの大部分、南米の大部分（ブラジルは2019年に廃止）、ロシア（2014年以降）、アイスランド、ハワイ、アリゾナ州の大部分、インド、中国、日本、韓国、トルコ。
このコンバーターは各IANAゾーンのDSTルールを考慮しているため、America/New_Yorkで設定した1月の午前9時のミーティングはEST（UTC−05:00）として変換される。同じ午前9時でも7月にはEDT（UTC−04:00）として変換される。
ソフトウェアにおけるDSTの落とし穴
- 「Spring forward」（時計を進める）：現地時計が02:00から03:00に飛ぶため、02:00〜02:59の1時間は存在しない。その時間帯に設定されたCronジョブはLinux Vixie cronでは跳躍直後に実行されるが、AWS EventBridgeでは完全にスキップされる。
- 「Fall back」（時計を戻す）：02:00から01:00への時計の巻き戻しが発生し、その時間帯が2回繰り返される。重複した時間帯のイベントはスケジューラーによって2回実行されることも、まったく実行されないこともある。Linux Vixieは再実行しない。AWS EventBridgeは1回のみ実行する。
- カレンダー招待はDST境界をまたぐ場合、現地時刻だけでなくタイムゾーンを明示する必要がある。そのためICSファイルには
TZIDが含まれている。受信者のカレンダーがDSTの切り替わりをまたぐとき、「9 AM ET」のような平文メールで送ると1時間ずれる可能性がある。
主な使用例
- 大陸をまたぐミーティングのスケジュール設定：午前9時PSTは東京やベルリンでは何時か？全員が業務時間内に重なるのはいつか？
- 製品リリースの調整：「深夜0時に一斉公開」または「各自のローカル時間の午前9時」に合わせたリリース。
- サーバーログを現地時刻で読む：サーバーがUTCに設定されている場合（クラウドサーバーの現代的なベストプラクティス）、ログのタイムスタンプを現地時刻に変換する。
- 旅行計画：現地時間で何時に到着するか？出発地での離陸時刻は目的地では何時か？
- 海外クライアントとの調整：タイムゾーンの計算を頭の中でする際の間違いを防ぐ。
- ライブイベントのスケジュール：ゲーム配信、ウェビナー、スポーツ中継など、世界中の視聴者に「今放送中？」という1つの回答を提供する必要がある場合。
よくある間違い
- 「EST」と「EDT」の混同（標準時と夏時間のどのペアも同様）。ニューヨークで3月1日と3月31日の同じミーティングはUTCオフセットが異なる。
- 「GMT」を「英国時間」の意味で使う。英国は3月下旬から10月下旬まで英国夏時間（BST、UTC+01:00）を採用している。冬だけがGMTだ。
- 都市のUTCオフセットが固定だと思い込む。ロシア、サモア、エジプトなどは過去15年でオフセットを変更している。IANAデータベースは履歴を追跡しているため、都市名と日付でのルックアップは常に正確だ。
- 3文字略語で招待を送る。「9 AM CST」はシカゴ（UTC−06:00）と上海（UTC+08:00）の間で14時間差があり、本当に曖昧だ。IANAゾーン名またはオフセットを含めること。
- アリゾナ、ハワイ、サスカチュワン、インディアナを忘れる。これらの場所はDSTを採用しないか、部分的にしか採用しない。「マウンテンタイム」や「セントラルタイム」という一般的なマッピングは年の半分で誤った結果になる。
- 存在しない時刻にミーティングを設定する。時計を進める日の現地時間02:30の招待は存在しない時間帯にあたる。カレンダーは通常サイレントにずらすが、エラーを出すシステムもある。
よくある質問
なぜ一部のオフセットが30分単位なのか？
歴史的・政治的な理由による。インドはUTC+05:30を採用したが、これは国の東西の範囲を妥協した結果だ。イラン、アフガニスタン、ミャンマーなども同様の30分単位のオフセットを使用している。ネパールはさらに進んでUTC+05:45を使用している。タイムゾーンが整数時間の境界でなければならないというルールはない。それぞれの管轄区域が自由に決定している。
このコンバーターはDSTの切り替えをどのように処理するか？
自動的に処理される。ブラウザのIANAデータベースは歴史的なものも含む各地域のDSTルールを収録している。夏の日付でEurope/Berlinに設定した時刻はCEST（UTC+02:00）を使って正しく変換される。同じ現地時刻でも冬はCET（UTC+01:00）を使って変換される。
どのタイムゾーンを追加できるか？
ブラウザが認識しているすべてのIANAタイムゾーンで、通常は人が住むすべての地域をカバーする400以上のゾーンが利用可能だ。ドロップダウンはページロード時にブラウザのIntl.supportedValuesOf('timeZone')から入力されるため、OSにインストールされたものが常に反映される。
変換された時刻はどこかに送信されるか？
いいえ。変換は組み込みのJavaScript日付・タイムゾーンAPIを使ってブラウザ内で完全に行われる。ミーティングの時刻、場所、選択したゾーンに関する情報はどのサーバーにも送信・記録・保存されない。
DSTの前後でミーティングの時刻がずれるのはなぜか？
一部のゾーンがDSTを採用し、他は採用しないためだ。太平洋時間の午前9時のミーティングは冬（両方が標準時）に東部時間の正午になるが、夏（両方がDST）でも同じく正午のままだ。ただし太平洋時間の午前9時のミーティングは東京では年間を通じて翌日の午前1時になる。東京はDSTを採用しないため、LAと東京の時差は年に2回1時間ずれる。
ミーティングの時刻を共有する最も安全な方法は？
カレンダー招待（.icsファイルまたはGoogle / Outlook / iCloudカレンダー経由）にタイムゾーンを明示して送ること。受信者のカレンダーは両端のDSTを自動的に考慮しながら、現地ゾーンで時刻を表示する。平文テキストで時刻を送る場合は、IANAゾーンとオフセットの両方を含めること：「火曜日 14:00 Europe/Berlin（UTC+01:00）」。