IANAタイムゾーンデータベースの正体
ソフトウェアで日付や時刻を扱ったことがあるなら、知らず知らずのうちにIANAタイムゾーンデータベースに依存しています。このデータベースはさまざまな名称で知られています — tzデータベース、tzdata、Olsonデータベース、zoneinfo — ですが、すべて同じものを指しています：世界中のタイムゾーンとそのルールをまとめた、共同で自由に利用可能なカタログです。
「カタログ」という言葉だけでは実態を軽く見積もりすぎです。このデータベースは、どの地域がどのUTCオフセットにあるかを単にリストするだけではありません。各地域における民間の時刻管理の完全な歴史 — オフセットの変更、夏時間の移行、戦時の時計変更、将来予定されているルール — を、多くの場合、地方平均時が標準化された19世紀半ばまで遡って記録しています。あなたのカレンダーアプリが、1985年の会議が同じ壁時計時刻より1時間ずれていた正しく表示するとき、それはtzデータベースの働きです。
テキストベースで人間が読め、サイズも小さいです。コンピュータに付属するコンパイル済みバイナリ形式はわずか数メガバイトです。しかし、コンピューティングでもっとも静かに複雑なデータセットの1つをエンコードしています。
短い歴史
このプロジェクトは1980年代、Arthur David Olsonによって始められ、彼が最初のバージョンをまとめ、米国国立衛生研究所のサーバーでホストしました。何十年もの間、公開メーリングリストで調整されたボランティアの努力によって主に維持され、そのため「Olsonデータベース」という古い名称が今でもドキュメントに残っています。
Paul Eggertが主要な編集者を引き継ぎ、長年にわたってプロジェクトの調整役を務めています。彼が編纂した付属のtheory.htmlドキュメントと細心のコミット履歴により、データベースは技術的な参考文献であると同時に歴史的な参考文献にもなっています。
2011年、歴史的データをめぐる短期間だが憂慮すべき法的紛争の後、管理権はInternet Assigned Numbers Authority (IANA)に移りました。これは他の中核的なインターネットリソースを調整するのと同じ機関です。IANAが現在公式リリースを公開しており、「IANAタイムゾーンデータベース」が正統な名称になりました。作業は今も同じコミュニティの貢献者によって行われています。IANAは制度的な拠点と安定した配布ポイントを提供しています。
命名規則: Area/Location
このデータベースの最も特徴的な点の1つは、タイムゾーンの命名方法です。国名や生のオフセットではなく、Area/Location形式を使用し、ほぼ常に代表的な都市に固定されます。
America/New_YorkEurope/LondonAsia/KolkataAustralia/Sydney
「Area」は通常、大陸または海洋（America、Europe、Asia、Pacific）であり、「Location」はそのゾーン内のよく知られた都市です。この選択は一風変わっていますが、その背後にある理由を理解すれば納得できます。
都市は安定していますが、政治的な境界やオフセットはそうではありません。 国は分裂、統合、改名、時計の変更を行います。これに対して、都市は地理的に固定された点であり、連続した時刻管理の歴史を持っています。ゾーンに「US Eastern Time」や「UTC-5」ではなくAmerica/New_Yorkと名付けることで、それに付随するルールが変化しても識別子は有効であり続けます。
データベースはまた、政治的な紛争を避けるため、また単一の国が複数のゾーンを含むことが多いため（米国だけでも十数個あります）、国名を意図的に避けています。各地域のゾーンの中で最も人口が多いか歴史的に重要な都市を中立的なラベルとして選びます。2つの地域が1970年以降同じ時計の歴史を共有している場合、それらは1つのゾーンを共有します。歴史が分岐した瞬間に、別々のエントリが与えられます。
生のオフセットだけでは不十分な理由
初心者がよく「UTC+5:30」として時刻を保存して完了とする傾向があります。これは単一の瞬間には機能しますが、将来のイベントや繰り返しのイベントについて推論する必要がある瞬間に破綻します。なぜならオフセットは場所の静的なプロパティではないからです。オフセットは、政府が頻繁かつ突然変更するルールの出力です。
データベースが吸収しなければならなかった実際の例をいくつか考えてみましょう。
- サモアは2011年12月30日を完全に飛ばしました。 ビジネス日を米国ではなくオーストラリアやニュージーランドに合わせるため、サモアは国際日付変更線を飛び越え、UTC-11からUTC+13に移動しました。島の人々にとって、その金曜日は単に存在しませんでした。
- 国々はほとんど予告なく夏時間を廃止、採用、または再スケジュールします。 EUはDST廃止を議論しています。いくつかの国や米国の州は過去数十年でDSTルールを変更しました。トルコ、ロシアなどは標準オフセット自体を直接変更しました。
- DSTの開始日と終了日は変動します。 米国は2007年にDSTの境界を移動させました。古いルールをハードコードしたシステムは、毎年数週間、静かに間違った時刻を生成していました。
オフセットだけを保存していると、「来年の11月15日にサンティアゴの現地時間は何時になるか？」という質問に答えることができません。答えは、まだ確定していないかもしれないルールに依存するからです。ゾーン識別子（America/Santiago）とデータベースを保存することで、ソフトウェアは過去または将来の任意の瞬間に対して正しいオフセットを計算でき、ルールが変更されたときに自動的に再計算できます。
これが中核的な価値提案です。tzデータベースは、場所の同一性と、その時計を決定する絶えず変化するルールを分離します。
どのように維持されているか
メンテナンスはオープンに行われます。提案された変更（新しいDSTルール、修正された歴史的な日付、政府の発表）は公開のtzメーリングリストで議論され、貢献者は公式官報、ニュースレポート、政府の法令を証拠として引用します。正確性は真剣に受け止められます。特に歴史的データへの変更は一次情報源と照合して精査されます。
リリースは年と文字でバージョン管理されます：2024a、2024b、2024cなど。数字は年、文字はその年のリリースごとに増えていきます。政府は時計の変更を予測不可能なスケジュールで発表するため、固定のリリース頻度はありません。平穏な年は2回のリリース、政治的な変動の多い年は多くのリリースがあります。システムは速やかに更新することが期待されます。古いデータベースはルール変更が有効になった後に間違った時刻を表示する可能性があるからです。
誰が依存しているか
ほとんどすべてのものが依存しています。
- オペレーティングシステム。 Linuxディストリビューションは
tzdataをコアパッケージとして提供します。macOSは同じソースからゾーンデータを派生させています。Windowsはレガシーな理由で独自のレジストリベースのゾーンを使用しますが、ICUライブラリや最新のAPIを通じてIANAゾーンを公開しています。 - プログラミング言語。 実質的にすべての成熟した日付/時刻ライブラリは、tzデータベースを読み込むかバンドルしています。Pythonの
zoneinfo、Javaのjava.time、ICUプロジェクト、PostgreSQL、ICUを介したJavaScriptエンジン、Ruby、PHPなど多数。 - アプリケーション。 カレンダー、予約システム、金融取引プラットフォーム、ログ分析ツール、スケジューリングサービスはすべてこれに依存しており、開発者は通常それを意識していません。
この遍在性こそが、このデータベースが非常に重要である理由です。単一で共有され、注意深く維持された真実の源泉により、あるシステムでスケジュールされた会議が、オペレーティングシステムや言語を越えて、数十年先または過去にわたって別のシステムで正しく表示されます。
ゾーン自体を探索したい場合は、IANAタイムゾーンの完全なリストを参照するか、全タイムゾーンのディレクトリでそれらが世界中にどのようにマッピングされているかを確認してください。
よくある質問
tzデータベースはtzdata、zoneinfo、Olsonデータベースと同じですか？
はい。これらはすべて同じプロジェクトの名称です。「tzdata」は通常、オペレーティングシステム用にパッケージ化されたデータファイルを指し、「zoneinfo」はコンパイル済みバイナリディレクトリを指し、「Olsonデータベース」は創設者Arthur David Olsonにちなんだ古い歴史的名称です。現在の正式名称はIANAタイムゾーンデータベースです。
データベースはどのくらいの頻度で更新されますか？
固定のスケジュールはありません。リリースは現実世界のイベント（政府のDSTルールや標準オフセットの変更、歴史的データの修正）によってトリガーされます。年に1回のリリースしかない年もあれば、複数回ある年もあります。それぞれ2024a、2024bのように命名され、文字がその年の間で増えていきます。
なぜAmerica/New_Yorkのように都市にちなんでゾーンを命名するのですか？
都市は地理的に固定され、連続した時刻管理の歴史を持っています。一方、国、国境、オフセットは時間とともに変化します。代表的な都市を使用することで、各ゾーンに安定した政治的に中立な識別子が与えられ、基盤となるDSTやオフセットのルールが変更されても有効であり続けます。
ゾーン名の代わりにUTCオフセットだけを保存してもいいですか？
単一の固定された瞬間に限ります。将来または繰り返しのイベントについては、ゾーン識別子を保存するべきです。オフセットは夏時間や政府の決定によって変化するからです。ゾーン名とデータベースを組み合わせることで、ソフトウェアは任意の日付に対して自動的に正しいオフセットを計算できます。
現在誰がプロジェクトを運営していますか？
IANAによって公開されており、2011年に管理権を引き継ぎました。Paul Eggertが調整役を務め、公開のtzメーリングリストで活動する貢献者のコミュニティとともに運営されています。技術的な作業は引き続き共同のボランティアによる取り組みです。