IANAタイムゾーンデータベース：インターネットを支える時刻の要

スマートフォンが海外旅行先で自動的に現地時刻に切り替わるのはなぜでしょうか。答えは「IANAタイムゾーンデータベース」——通称tz database（tzデータベース）です。世界のほぼすべてのOS、プログラミング言語、サーバーが依存している、知る人ぞ知る重要インフラです。

tzデータベースとは

tzデータベースは、世界各地のタイムゾーンと、その歴史的な変更履歴を記録した公開データベースです。1986年にArthur David Olson氏が始め、現在はIANA（Internet Assigned Numbers Authority）がホストし、ボランティアのメンテナーたちが更新を続けています。

収録されているのは単なる「UTCからのオフセット」ではありません。各都市について、1970年以降（多くはそれ以前から）の標準時・サマータイムの全変更履歴が秒単位で記録されています。

「America/New_York」形式の識別子

tzデータベースでは、タイムゾーンを「地域/都市」形式の識別子で表します。

• Asia/Tokyo（日本）
• America/New_York（米東部時間）
• Europe/London（英国時間）
• Australia/Sydney（シドニー）

都市名はそのタイムゾーンを代表する人口の多い都市が選ばれ、同じ国でも州ごとに異なるルールがあれば別のエントリになります（例：America/Phoenix はサマータイムを実施しないアリゾナ州用）。

なぜオフセットだけでは不十分なのか

「UTC+9」とだけ記録すると、次の問題に対処できません。

• サマータイム：同じ都市でも夏と冬でオフセットが変わる。しかも切り替え日は国ごとに異なり、法律改正で変わることもある。
• 歴史的変更：2011年にサモアが日付変更線をまたいで曜日を1日飛ばした例のように、ルールは突如変わる。
• 未来の予定：欧州のサマータイム廃止論のように、将来のルール変更を配信する仕組みが必要。

tzデータベースは年に数回更新され、各国政府の発表を反映します。OSのアップデートにタイムゾーン情報の更新が含まれているのはこのためです。

開発者にとっての意味

JavaScriptの Intl.DateTimeFormat、Pythonの zoneinfo、Javaの java.time など、主要な言語の日時APIはすべてIANA識別子を受け付けます。「UTC+8」のような固定オフセットで時刻を保存すると、将来ルールが変わったときに過去・未来の時刻が壊れます。必ずIANA識別子で保存するのが定石です。

世界時計アプリとの関係

信頼できる世界時計は、内部でIANAデータベースにもとづき各都市の現地時刻を計算しています。だからこそ、サマータイムの切り替え日にも自動で正確に対応できるのです。

まとめ

• tzデータベースは世界のタイムゾーン履歴を記録する公開DB。
• 「Asia/Tokyo」形式の識別子で都市ごとのルールを管理。
• 固定オフセットではサマータイムや法改正に対応できない。
• 世界中のOS・言語がこのボランティア運営のDBに依存している。