タイムゾーン変換機

この計算について

タイムゾーンをまたいだ会議のスケジュール調整は、リモートワークにおける日常的な課題です。「パリ時間火曜午後4時」は、パリにいる人には明確ですが、それ以外の人には曖昧です。それは太平洋夏時間午前7時なのか、それとも太平洋標準時午前7時なのか、春か秋かによって変わります。夏時間（DST）は、半球間（シドニーはパリが春に進むときに後退します）や年代（2024年には南米のほとんどがDSTを完全に放棄しました）で異なります。IANA tzdataプロジェクトは、すべての名前付きタイムゾーンとそのオフセット履歴の正準マッピングを維持しており、すべての最新ブラウザは、ルールを自動的に処理するローカルコピーを搭載しています。この計算機は、そのデータに対するユーザーインターフェースです。日付、現地時刻、およびソースタイムゾーンを入力し、宛先タイムゾーンを選択すると、宛先での同等の現地時刻と、その特定の瞬間の2つのゾーン間のオフセットが得られます。ドロップダウンの20都市は、クロス・タイムゾーン会議の大部分をカバーしています：主要なヨーロッパの首都、米国の本土ゾーン、4つの主要なアジアのビジネスハブ、南半球のビジネス都市、および曖昧さのない基準としてのUTCです。

計算式

閉じた形式の式はありません。計算機はブラウザのIntl.DateTimeFormat APIに委譲しており、これはオペレーティングシステム経由でIANA tzdataにアクセスできます。内部的には：(1) 入力された現地時刻をソースタイムゾーンで解釈したときに、ユーザー指定の現地時刻を表示するUTCインスタントを構築します。これには小さな2パスループが必要です。入力をUTCとして扱い、Intlにそのインスタントでソースゾーンが何を表示するかを尋ね、表示された現地時刻と意図した現地時刻とのオフセットを計算し、そのオフセットを引いて実際のUTCインスタントを見つけます。(2) 同じUTCインスタントを宛先ゾーンでIntl.DateTimeFormatとtimeZone: <宛先>を使用してフォーマットします。(3) オフセットは固定ではないため、DSTによって変化するため、その特定のインスタントにおける2つのゾーン間のオフセット差を計算します。結果には、明確にするために曜日、完全な日付、時分、およびゾーン略称（CET、EST、JSTなど）が含まれます。

使用方法

4つの入力：日付（日付ピッカー）、時間（24時間制タイムピッカー）、ソースタイムゾーン（ドロップダウン）、宛先タイムゾーン（ドロップダウン）。デフォルト：今日14:30、パリからニューヨークへ。結果パネルには、ソース時刻と宛先時刻が2つの大きな並列KPIとして表示され、その下にはUTC基準時刻と、その瞬間の2つのゾーン間のオフセットが表示されます。20都市のドロップダウンは、ヨーロッパ（パリ、ロンドン、ベルリン、モスクワ）、アメリカ（ニューヨーク、シカゴ、デンバー、ロサンゼルス、サンパウロ）、アフリカ（カイロ、ヨハネスブルグ）、アジア（ドバイ、ムンバイ、北京、東京、シンガポール、ソウル）、オセアニア（シドニー、オークランド）、およびUTCをカバーしています。ドロップダウンを編集して新しい都市を追加できます。基盤となるメカニズムは、任意のIANAゾーン識別子を処理します。

計算例

パリのチームが、2026年5月15日14:30パリ時間でニューヨークの担当者とのキックオフ会議をスケジュールしたいと考えています。ソース：2026年5月15日14:30、Europe/Paris（CEST、5月はDSTが実施されているためUTC+2）。宛先：America/New_York（EDT、5月はUTC-4）。ソースからUTCへ：14:30 - 02:00 = 12:30 UTC。UTCから宛先へ：12:30 + (-04:00) = 08:30 EDT。したがって、14:30パリ時間は、同日08:30ニューヨーク時間となり、オフセットは6時間です。次に、2026年1月15日14:30パリ時間（CET、UTC+1）→ニューヨーク（EST、UTC-5）を考えます。ソースからUTCへ：14:30 - 01:00 = 13:30 UTC。UTCから宛先へ：13:30 - 05:00 = 08:30 EST。壁時計での変換は同じですが、それはパリとニューヨークの両方が標準時間であったためです。もしパリが夏時間になり、ニューヨークがそうならなかった場合（毎年3月下旬に起こる実際の状況）、オフセットは6時間ではなく5時間になります。計算機はこれを透過的に処理します。ユーザーは2つのゾーン間のDSTを追跡する必要はありません。IANAデータベースがそれを処理します。より劇的な例：2026年12月15日09:00シドニー（AEDT、UTC+11）→ロンドン（GMT、UTC+0）。ソースからUTCへ：09:00 - 11:00 = -02:00 UTC、これは前日の22:00です。ロンドン時間12月14日22:00 — カレンダー terms では日付線を越えますが、時計 terms では11時間差です。

一般的な注意点

第一に、UTCオフセットとタイムゾーンの混同。「UTC+1」はオフセットを記述し、「Europe/Paris」はタイムゾーンを記述します。パリは冬はUTC+1、夏はUTC+2です。フランス時間としてUTC+1をハードコーディングすると、3月下旬から10月下旬まで1時間の誤差が生じます。第二に、DSTの無視。パリとニューヨークは両方ともDSTを適用しますが、スケジュールが異なります。3月中旬には、ニューヨークが既にEDT（UTC-4）に切り替わった後も、パリは2週間CET（UTC+1）のままです。この期間のオフセットは6時間ではなく5時間になります。計算機はこれを処理しますが、手動での変換は通常間違えます。第三に、12時間制と24時間制の表記の混同。米国と英国は日常的に12時間制（AM/PM）を使用しますが、大陸ヨーロッパは24時間制を使用します。計算機のピッカーは24時間制で、宛先出力も曖昧さがないように24時間制を使用します。第四に、日付線の横断を気づかずにスケジュールすること。火曜日の午前9時の東京は、月曜日の午後5時のサンフランシスコです。16時間のオフセットで、カレンダーの日付をまたぎます。計算機は、これを視覚化するために、宛先での完全な日付を表示します（時刻だけでなく）。第五に、コンバーターを法的または航空用途の権威として扱うこと。計算機はブラウザのtzdataを使用しており、OSが更新されるときに更新されます。ユーザーが古いシステムを使用している場合、最近のDSTの変更（例：ブラジルの2019年のDST廃止、メキシコの2022年のDST部分的廃止）に対するルールが古い可能性があります。拘束力のあるコンテキストについては、常に公式ソースでクロスチェックしてください。

バリエーションとコンテキスト

タイムゾーンは政治的に流動的なシステムです。DSTの変更は一般的です。EUは2018年からDSTの終了を議論していますが（2025年現在、合意には至っていません）。ロシアは2014年にDSTを廃止しました。メキシコは2022年にほとんどの地域でDSTを廃止しました。イランは2022年にDSTを廃止しました。IANA tzdataプロジェクトは、これらすべての変更を追跡し、年に数回アップデートをリリースします。最新のオペレーティングシステムはこれらを自動的に取得します。30分および15分オフセットが存在します。インドはUTC+5:30、イランUTC+3:30、ニューファンドランドUTC-3:30、ネパールUTC+5:45、チャタム諸島UTC+12:45です。IANAが処理するため、計算機はこれらを透過的に扱います。極地は、管理上都合の良い時間帯を使用します。南極基地は、供給国の時間に従う場合があります。歴史的な変換（1956年のベルリンからニューヨークへの会議時間）もIANAによってサポートされており、各ゾーンのオフセット履歴全体が記録されています。コードでのプログラムによる変換は、常にタイムスタンプをUTCで保存し、表示時にのみローカル時間に変換すべきです。この計算機は、ユーザーが結果を見る境界での変換を示しています。