「UTC+9」と Asia/Tokyo。この2つを同じ列に並べて書いたことはないでしょうか。設定画面のプルダウン、仕様書の項目名、集計ツールの表示。いずれも「タイムゾーン」という同じ見出しの下に置かれます。
最初は、単に表記の長短の違いだと考えていました。Asia/Tokyo は長いので、短い +09:00 で持っておけば同じことだ、と。
しかし公式の設計文書を読み直すと、この2つは別の種類のものでした。+09:00 は数値です。Asia/Tokyo は数値の略記ではなく、いつからいつまではどの規則が適用されたかという履歴に付いた名前です。そして同じ文書が、このデータベースは権威ある情報源ではないと自ら書いています。
本記事が立てる仮説はこれです——識別子を数値の別名として扱うと、データベースが保証していない範囲に無自覚に依拠することになるのではないか。
この見立てが当たっているなら、起きる失敗は静かです。日次の集計が1時間だけずれる。日付の境界で件数が隣の日に移る。原因が「変換の実装」ではなく「変換が依拠している前提」の側にあると、コードを読み直しても見つかりません。
本記事は識別子とは何であり、このデータベースは何を保証していないかに絞ります。日時をどの型で保存するか、将来の予定をどう持つか、境界をどうテストするかという設計の判断は「日時はUTCで保存すれば安全」は、どこまで正しいのかで扱っているため、ここでは繰り返しません。解析ツール側の集計境界の設定にも踏み込みません。
30秒で要点
- 公式の設計文書は、タイムゾーンの「基準オフセット」という概念そのものが成り立たない場合があり、それは必ずしも単一の数値ではないと述べている
- 識別子が対応するのは規則の集合であり、1年に2回を超える変更がありうるうえ、2つの選択肢を往復するだけとも限らず、規則そのものも時とともに変わりうる
- IANA は、このデータベースが世界各地の地方時の履歴を表すコードとデータを含み、政治的機関による境界・オフセット・夏時間規則の変更を反映して定期的に更新されると説明している
- 文書は、このデータベースは権威ある情報源ではなく確実に誤りを含むと自ら述べ、1970年以前の項目の多くは出典を欠く信頼できない情報源に由来すると書いている
- 将来のタイムスタンプは予測であり、将来政府が規則を変えれば現在の予測は誤りになると明記されている
- 利用者は特定のオフセットや略称に依拠すべきではない。データ項目はしばしば推測に基づいており、その推測は修正・改善されうると文書は述べている
- したがって「オフセット」は土地に貼り付いた属性ではなく、規則の履歴のある一点を読み出した結果である
公式文書は「基準オフセット」が成り立たない場合があると書いている
参照するのは IANA が配布している tz データベースの設計文書 theory.html です（2026年10月21日に取得して確認）。
この文書には、読み飛ばしやすい一文があります。タイムゾーンが時計を変えるかどうか、いつ変えるか、そして想定上の協定世界時からの基準オフセットさえも可変である、と述べたうえで、こう続きます。タイムゾーンの「基準オフセット」について語ることは必ずしも意味をなさない。それは必ずしも単一の数値ではない、と。
ここで否定されているのは「オフセットの値」ではありません。「この地域の基準オフセットは何か」という問いの立て方そのものです。
もう1つ、規則の範囲についての記述があります。tz のタイムゾーンは、1年に2回を超える変更を持ちうる規則集合に対応しており、これらの変更は2つの選択肢を単に往復するだけとは限らず、規則そのものも時とともに変わりうる、と書かれています。
この2つを合わせると、識別子が指しているものの形が見えてきます。識別子は値ではなく、規則の集合に付いた名前です。そして規則の集合は、固定された表ではありません。
命名規約に表れている設計の意図
文書は名前の付け方も定めています。名前は通常 AREA/LOCATION の形式を取り、AREA は大陸または海洋です。名前は国名が変わったときの非互換を避けるため、通常は国に紐づけません。使うのは国や地域ではなく都市や小島です。そして、すべての国・首都がタイムゾーン名を持たなければならないという要件はない、と書かれています。
Asia/Tokyo の Tokyo は、東京という都市の時刻を意味しているのではありません。規則の集合を一意に名指すための識別子として都市名が選ばれています。国に紐づけない理由が「国名が変わりうるから」である点は、この命名規約が何を避けようとしているかを示しています。名前の安定性です。
識別子が指しているのは、更新され続けている履歴である
IANA のタイムゾーンデータベースのページは、このデータベースの中身を次のように説明しています。tz または zoneinfo としばしば呼ばれるこのデータベースは、世界各地の代表的な地点について地方時の履歴を表すコードとデータを含んでおり、政治的機関によるタイムゾーン境界・協定世界時オフセット・夏時間規則の変更を反映して定期的に更新される、と。
「履歴」という語が、ここでの核になります。データベースが持っているのは現在の対応表ではなく、時間軸を持った記録です。
更新が続いていることも、同じページから確認できます。2026年10月21日に確認した時点で、公式ページが示している現行リリースの表記は 2026e（Released 2026-09-29）で、変更内容の1つとして「Manitoba moves to permanent -05 on 2026-10-31.」が挙げられています。マニトバが特定の日付から恒久的なオフセットへ移る、という内容です。
ここで注意しておきたいのは、更新の頻度を数値で語らないことです。参照した2つの文書はどちらも「年に何回更新される」という記述を持っていません。言えるのは「定期的に更新される」という文書の記述と、確認した時点のリリース表記までです。
データベースは、自分が保証していない範囲を自分で書いている
ここが本記事の山場です。設計文書は、自らの限界について踏み込んだ記述を持っています。
まず、tz データベースは権威ある情報源ではなく、確実に誤りを含む、と書かれています。
続けて、1970年以前の項目については、このデータベースが収めているのは実際に時計がどう振る舞ったかのごく一部にすぎず、必要な情報の大半は失われたか、そもそも記録されなかったと述べています。さらに、1970年以前のデータ項目の多くは信頼できない情報源に由来し、それはしばしば出典を欠く占星術の書籍であって、その編者は真相が不明なときに項目を創作したと見られ、どの項目が既知でどの項目が創作かを報告していない、と書かれています。
そして結論として、このデータベースの1970年以前と将来のタイムスタンプの多く、おそらく大半は、誤っているか誤解を招くものである、と記しています。
この記述の範囲は、正確に押さえておく必要があります。対象は1970年以前と将来のタイムスタンプです。1970年以降の確定した過去について同じ評価が下されているわけではありません。評価の対象を広げると、文書が書いていない主張になります。
限界の記述はもう1つあります。このデータベースは、あらゆる場所のあらゆる過去の時刻を正確に扱うことを要求する用途のために設計されておらず、十分でもない、と文書は述べています。理由として、1970年以前の市民生活上の時刻管理のすべての詳細を記録するには、あまりにも多大な労力と推測が必要になるからだと書かれています。
この一文は、限定を落とすと意味が変わります。「正確な取り扱いを要求する用途には十分でない」と短くしてしまうと、現在や近い過去の扱いにも不適だという別の主張になります。文書が置いている限定は「あらゆる場所のあらゆる過去の時刻」です。
将来の日時は、まだ決まっていない
文書は将来についても明示しています。tz データベースは将来のタイムスタンプを予測しており、将来政府が規則を変えれば現在の予測は誤りになる、と。
挙げられている例が具体的です。今日、誰かがダブリン時間の次の10月1日13時に会議を設定し、翌日アイルランドが夏時間の規則を変えた場合、変更前に行った換算に素朴に依拠するとソフトウェアが破綻しうる、という例です。
この例が示しているのは、将来の日時についての換算がその時点の予測の写しであるという性質です。写しを保存した側は、元の予測が更新されたことを知る手段を持ちません。
略称もオフセットも、依拠してよい取り決めではない
文書は、利用者が特定の協定世界時オフセットや略称に依拠すべきではないと述べています。理由として、データ項目はしばしば推測に基づいており、その推測は修正・改善されうるからだと書かれています。タイムゾーンの境界についても、外部が依拠してよい安定した取り決めの一部ではないと明記されています。
略称については警告がより具体的です。アプリケーションの作者は、これらの略称が実務上あいまいであることに注意すべきだとしたうえで、CST は中国と北米で別の意味になり、IST はインド・アイルランド・イスラエルのいずれの時刻も指しうる、と例を挙げています。そしてあいまいさを避けるため、CST のようなタイムゾーンの略称ではなく、-0600 のような数値の協定世界時オフセットを使うよう勧めています。
断っておくべき点があります。この文書に、日本で使われる略称を名指しした警告はありません。挙げられている例は上記の2つです。「公式文書が特定の略称を使うなと書いている」という形で日本の事例に当てはめると、文書が書いていないことを書いたことになります。
ここまでで、2つの表記のどちらにも限界があることが見えます。略称はあいまいで、オフセットは依拠すべきでないと文書自身が述べている。残るのは識別子ですが、その識別子が指しているのは、誤りを含むと文書が認めている履歴です。
なぜ「オフセットは土地の属性」と考えたくなるのか
ここまでの記述を読んでも、実務では +09:00 が属性のように扱われ続けます。理由は3つに分けられます。
第一に、ほとんどの場面で両者の区別が結果に現れないからです。 現在の日時を扱っているあいだ、識別子を解決した結果は安定した1つの数値になります。区別が結果に出ないものは、区別する必要がないものとして扱われます。差が出るのは、規則が変わった時期をまたぐときと、将来の日時を扱うときだけです。
第二に、表示の形が数値に揃っているからです。 ログ、入出力、画面表示。実際に目にするのはほとんど数値です。Asia/Tokyo は設定の中に一度書いたら、あとは見えません。見えている形が、持っているものの形だと感じられます。
第三に、壊れ方が静かだからです。 規則の取り違えは例外を投げません。変換は成功し、数値は返り、処理は完走します。ずれるのは件数と境界だけです。例外にならない誤りは、誤りとして報告されません。 報告されないものは、原因の候補にも上がりません。
3つが重なると、「オフセットを持っておけば足りる」という判断が最初に来て、しかも反証されないまま残ります。
判断軸：この値は、履歴のどこに依拠しているのか
ここからは本記事の判断です。参照した文書は、アプリケーションが何を保存すべきかを指示していません。述べているのは識別子の命名規約と、略称を避けるべきこと、そして自らの限界です。
そのうえで、文書の記述から引ける問いは1つに絞れます。いま手元にあるこの値は、履歴のどこに依拠しているのか。
表が収まらない場合は、横にスクロールできます
| 値の種類 | 文書の記述に照らした性質 | 確認しておくこと |
|---|---|---|
| 確定した過去の瞬間（1970年以降） | 文書の限界の記述の対象外。規則が確定している範囲 | その瞬間が規則の変更時期をまたいでいないか |
| 1970年以前の日時 | 文書自身が、項目の多くが誤っているか誤解を招くと述べている範囲 | その精度が用途に足りるかを、用途の側から判断する |
| 将来の日時 | 文書自身が、政府の規則変更で現在の予測が誤りになると述べている範囲 | 予測の写しではなく、再計算できる参照を保持しているか |
| 略称 | 文書が実務上あいまいだと警告している表記 | どの地域の規則を意味しているか、略称の外側に記録があるか |
この表は保存方法の推奨ではありません。どの値がどの保証の下にあるかの区分です。区分が付いていれば、「この数字は信用していい」と「この数字は推定である」を分けて扱えます。
区分が付いていないと、全部が同じ確度の数字として並びます。並んでしまえば、平均も差分も取れてしまいます。
手元で試せる最小の確認
自分のシステムが依拠している範囲を知るには、1つの棚卸しから始められます。日時の変換を直すのではなく、どの範囲に依拠しているかを数える作業です。
分母と分子を先に決めます。
- 分母：いま保存されている日時のうち、集計や表示で地方時に変換しているレコードの件数
- 分子：そのうち、1970年より前の日時、または将来の日時に属する件数
- 単位：推定依拠率（％）
手順は3つです。
- 変換に使っている値の種類を1件ずつ確認する。 識別子なのか、オフセットの数値なのか、略称なのか。混在していることが多い箇所です
- 推定依拠率を出す。 分子に入った件数は、文書が「誤っているか誤解を招く」と述べた範囲、または予測の範囲に属します。率そのものの高低ではなく、その件数が存在することを知っているかどうかが目的です
- 分子に入った1件を選び、用途の側から精度を言い直す。 その1件について、何分のずれまでなら業務が成立するのかを文章で書きます。書けないなら、精度の要件が決まっていないということです
3番目が要です。文書は、自らがあらゆる場所のあらゆる過去の時刻を正確に扱う用途には十分でないと述べています。十分かどうかは、用途の側が条件を言えて初めて判定できます。 条件を書いていない状態では、足りているとも足りていないとも言えません。
確かなことと、確かでないこと
確かなこと（2026年10月21日に情報源を取得して確認した範囲）：基準オフセットという概念が必ずしも意味をなさず単一の数値とは限らないという記述、規則集合が年2回の往復に限られないという記述、データベースが権威ある情報源ではなく誤りを含むという記述、1970年以前の項目の多くが出典を欠く信頼できない情報源に由来するという記述、1970年以前と将来のタイムスタンプの多くが誤っているか誤解を招くという結論、あらゆる場所のあらゆる過去の時刻を正確に扱う用途には設計されておらず十分でもないという記述、将来のタイムスタンプが予測でありダブリンの会議の例、略称のあいまいさと数値オフセットの推奨、特定のオフセットや略称に依拠すべきでないという記述、命名規約、IANA のページが地方時の履歴であり定期的に更新されると説明していること。
確かでないこと：参照した設計文書は tz データベースの設計方針を述べたものであり、他の時刻規格が同じ立場を取るかは今回確認していません。この文書に単一の最終更新日の記載はなく、本文が現行版として言及している規格を見るかぎり更新され続けている文書です。更新の頻度も、参照した文書には数値での記述がありません。
本記事が踏み込んでいないこと：日時の保存方法の設計判断（既存記事の担当範囲です）、各プログラミング言語・各ライブラリがこのデータベースをどう参照しているか、解析ツールの集計境界の設定、特定の国や年のデータが実際に誤っているかどうかの個別判定。文書は全体としての限界を述べていますが、個別の項目についての評価は書いておらず、今回それを検証してもいません。
識別子を扱うときに立ち返る問い
立ち返りたいのは、「この値は、何を約束しているのか」という問いです。+09:00 は、その瞬間の差を約束しています。地域の規則がこれからも同じであることは約束していません。Asia/Tokyo は、規則の集合を一意に名指すことを約束しています。その集合の中身が正しいことは、文書自身が約束していません。
もう1つは、「この数字は、確定した記録なのか推定なのか」という問いです。同じ形式で並んだ日時のあいだに、この違いは表示されません。表示されない区別は、区別する人がいなければ消えます。
タイムゾーンの扱いが難しいのは、規則が複雑だからというより、規則の履歴という時間軸を持ったものを、1つの数値として受け取れてしまうからです。受け取れてしまう形式が、区別を保存してくれないという話でもあります。
参考資料・引用元
- Theory and pragmatics of the tz code and data — IANA Time Zone Database（2026年10月21日に取得・HTTP 200。この文書に単一の最終更新日の記載はない）
- Time Zone Database — IANA（2026年10月21日に取得・HTTP 200。確認時点の現行リリース表記は 2026e、Released 2026-09-29）