Moment Timezone ガイド

このガイドセクションは、開発者が日付と時刻の問題領域、そしてMoment Timezoneライブラリをより効果的に活用できるよう支援するために設計されています。これらのガイドは、特にタイムゾーンとそのMoment Timezoneによる処理方法に関する概念に限定されています。

より一般的な日付と時刻に関するアドバイスについては、Moment.jsコアガイドを参照してください。

多くの場合、タイムゾーンとUTCオフセットの違いについて混乱が生じます。

Moment.jsのコアドキュメントには、このトピックに関するガイドがあり、最初に読む価値があります。論理的には、Moment Timezoneのガイドに属していますが、このガイドセクションより何年も前に作成されており、移動するとインターネット上の多くのリンクが壊れてしまいます。

ゾーンとオフセットの詳細な説明については、Stack Overflowタグを参照してください。

Moment Timezoneは、事前にコンパイルされたタイムゾーンデータを使用して、Moment.jsのコア機能を拡張します。

このセクションでは、データのソース、その制限、および現実世界のタイムゾーンルールに関するいくつかの特殊性を説明します。データ形式の技術的な詳細は、APIドキュメントで説明されています。

Moment Timezoneのすべてのタイムゾーンデータは、IANA Time Zone Database ("tzdb")から取得されます。Moment Timezoneは、公開されたリリースのみを使用して、tzdbから直接デフォルトデータを使用します。ライブラリが行う変更は、データをカスタムJSON形式に変換することと、オプションで使用するデータの年数を制限することだけです。

tzdbリリースから派生していないコンパイル済みデータファイルに対する変更を行うプルリクエストは、すべて拒否されます。

Moment Timezoneで使用されているデータが正しくないと思われる場合は、次の手順に従うのが理想的です。

1. ライブラリの最新バージョンにアップグレードしていることを確認してください。私たちはtzdbリリースを綿密に追跡しようとしているため、Moment Timezoneをアップグレードすることで、ほとんどの場合、データの期限切れの問題は解決されます。
2. データ計算の問題については、Moment Timezoneの問題トラッカーで問題を提起してください。
3. その他の問題（新しいゾーン定義の作成など）については、tzdbメーリングリストのアーカイブを検索してください。新しいデータの変更やゾーンの定義が既に議論されている可能性がありますが、まだ公開リリースには含まれていません。
4. tzdbアーカイブに何もない場合は、[email protected]のメーリングリストにメッセージを送信してください。

デフォルトでは、Moment TimezoneにはIANA Time Zone Database ("tzdb")のすべてのデータが含まれています。これには、一部のゾーンでは1800年代までさかのぼる過去のデータと、2499年までの将来のデータが含まれます。これは通常、ほとんどのアプリケーションに必要なデータ量よりも多いため、より限定された年範囲を持ついくつかの事前に構築されたデータバンドルも用意されています。プロジェクトホームページと"使用方法"ドキュメントに一覧表示されています（または、ユーティリティ関数を使用してカスタム日付範囲を作成することもできます）。

これらの限定的なバンドルでよく出てくる質問は、「データ範囲外の日の場合はどうなるのか？」です。たとえば、読み込まれたデータが2012年から2022年までの範囲のみをカバーしており、2023年または2010年の日付を計算する場合、その日付の計算されたUTCオフセットはどのようになりますか？

データ形式の構造上、データ範囲の境界におけるタイムゾーンルールは、過去と未来に無限に拡張されると想定されています。これにより、次の動作が発生します。

• データ範囲の開始日より前の日付については、そのタイムゾーンのデータで最初に検出されたルールが使用されます。
• データ範囲の終了日より後の日付については、そのタイムゾーンのデータで最後に検出されたルールが使用されます。

例として、プロジェクトで2015年から2025年までの範囲のみをカバーするデータファイルを使用しており、2026年のオーストラリアのシドニーの時間を計算するとします。

• Australia/Sydneyゾーンの基本（標準）オフセットは、毎年4月から9月まではUTC+10:00です。シドニーのサマータイム（DST）は10月から3月まで適用され、オフセットはUTC+11:00になります。
• DSTは年が変わり、したがってデータ範囲が終了する際に有効になるため、DSTオフセットは将来の日付すべてに使用されます。
• したがって、1月から3月の2026年の日付を計算すると、オフセットはUTC+11:00になります。これは正しいですが、あくまで*偶然*です。2026年3月以降の日付を計算しても、オフセットはUTC+11:00のままであり、実際の値はUTC+10:00であるはずです。ここでバグが発生し始めます。

これらの計算問題の最良の解決策は、プロジェクトに必要なすべての日付をカバーするデータ範囲を使用していることを確認することです。

サマータイム（DST）を使用するタイムゾーンは、時間ジャンプの実装時期が異なります。ローカルタイムゾーンで慣れ親しんでいるルールが他のゾーンにも適用されるとは限りません。

開発者をしばしば悩ませる違いの1つは、一部のゾーンが真夜中に時計を変更することです。良い例として、2021年のヨルダン（Asia/Amman）があります。

• 2021-03-25 23:59:59の1秒後が2021-03-26 01:00:00（DST開始）でした。
• 2021-10-29 00:59:59の1秒後が2021-10-29 00:00:00（DST終了）でした。

これにより、3月26日の開始時刻の真夜中が**発生しなかった**一方で、10月29日の真夜中は2回発生するという状況が生じます。

Moment Timezoneは、"曖昧な入力の解析"ドキュメントで説明されているように、これらの特異性を考慮しています。しかし、アプリケーションは、時間ジャンプに関する他の仮定、特に1日の開始に関する仮定を行う際に、依然としてバグが発生する可能性があります。そのため、**1日は必ずしも真夜中から始まるわけではない**ことを認識してください。