TZif（zoneinfo）ファイル解析ツール

使い方

1. コンパイル済みのゾーンファイルをドロップしてください。/usr/share/zoneinfo からコピーしたもの、docker cp でコンテナから取り出したもの、JDK から取り出したものが使えます。
2. まずサマリーを見ます。バージョン、遷移の件数、そして将来が列挙されている（fat）のか、POSIX 規則に任されている（slim）のか、固定なのかが分かります。
3. ヘッダーの 2 列を見比べます。slim なファイルではほぼ空の 32 ビットブロックと中身の詰まった 64 ビットブロックが並びますが、これは破損ではなく設計どおりです。
4. 基準時刻と次の遷移を見れば、このファイルが今日どのオフセットを返し、次にいつ変わるかが分かります。
5. slim なファイルでは POSIX フッターの節を開いてください。最後の遷移より後の日付は、そこにある M・J・0 起算の規則だけで決まります。

よくある質問

なぜヘッダーのカウントが 2 組あるのですか。

バージョン 2 以降のファイルが本当にデータを二度持っているからです。まず遷移時刻が 32 ビットのバージョン 1 ブロックが丸ごと入り、その後に 2 つ目のヘッダーと 64 ビットブロック、最後に POSIX フッターが続きます。2004 年より前に書かれたリーダーが失敗せずに読めるようにするための構造で、RFC 8536 は現代のリーダーに 2 つ目のブロックへ飛ぶよう指示しています。だからカウントが違っていて構いません。zic の slim 出力では最初のブロックがタイプ 1 個・遷移 0 件まで削られ、本当のデータは 2 つ目に入ります。あるツールがこのゾーンには履歴がないと言うなら、たいてい旧式ブロックを読み違えており、いまだにそう動くライブラリもあります。

fat なファイルと slim なファイルは何が違うのですか。

同じゾーンを表しますが、将来をどれだけ書き出すかが違います。fat は 2037 年までの全遷移を並べるので Europe/Berlin なら約 140 件入り、今年 10 月の切り替えも表から直接読めます。slim は規則から導けない最後の遷移で止め、その先を POSIX フッター文字列に任せるため、サイズが 10 分の 1 になることもあります。2020 年以降 zic の既定は slim ですが配布物によって異なり、Debian と Ubuntu は今も fat を配り、Alpine をはじめ多くのコンテナベースイメージは slim を配ります。フッターを無視するリーダーは fat では正しく動き、slim では来年を静かに間違えます。特定のイメージでだけ再現するバグの正体はたいていこれです。

POSIX フッターはどう読み、M・J・数字だけの形式は何を意味しますか。

フッターは TZ 環境変数に入れる文字列と同じ形式で、標準時の略称、標準時のオフセット、任意で夏時間の略称とオフセット、そして両者を切り替える 2 つの規則から成ります。オフセットは POSIX 流でグリニッジより西が正なので、CET-1 は UTC+01:00 を意味し、このツールは符号を戻して表示します。規則には 3 つの形式があります。Mm.w.d は月・週・曜日で、週が 5 なら最終週なので M3.5.0 は 3 月の最終日曜です。Jn は 1 から数える年内日で 2 月 29 日を決して数えないため J60 は常に 3 月 1 日です。数字だけの形式は 0 から数え 2 月 29 日を含むので、59 は平年なら 3 月 1 日、閏年なら 2 月 29 日です。最後の形式はまれで実装によって解釈が割れ、Python の zoneinfo は glibc より 1 日遅く解釈します。

Etc/GMT+5 のオフセットがなぜ -05:00 と表示されるのですか。

Etc 系の名前が POSIX の符号規約に従っており、それが他のあらゆる場所と逆だからです。TZ 文字列では正がグリニッジより西を意味します。したがって Etc/GMT+5 は UTC より 5 時間遅いゾーンで、ISO 8601 でも画面上でもそれは -05:00 と書きます。逆に Etc/GMT-5 が 5 時間進んだ側です。tz データベースは POSIX がその動作を要求するためこれらの名前を残しつつ、罠であると警告しています。このツールはオフセットを ISO 流で表示するので、名前が +5 でオフセットが -05:00 なのは矛盾でもバグでもなく、命名規約が表に出ているだけです。

うるう秒レコードとは何で、right/ のファイルの遷移時刻はなぜ変に見えるのですか。

tz データベースは 2 通りにコンパイルできます。タイムスタンプがうるう秒を含まない秒数である通常の posix/ ツリーと、1972 年以降のうるう秒をレコードとして持ち、タイムスタンプが実際の経過秒を数える right/ ツリーです。多くのシステムは前者しか配らないので、ここにうるう秒表が出るなら right/ のファイルか、誰かが zic -L でコンパイルしたファイルです。そうしたファイルでは遷移が累積補正の分だけずれ、01:00:00 のはずの切り替えが 01:00:27 と表示されます。1972 年以降に 27 回のうるう秒が挿入されたためで、補正の列も同じ 27 まで増えます。posix/ の時刻を前提とするシステムに right/ のファイルを混ぜると、ちょうど 27 秒ずれます。

このファイルがどのゾーンか、また壊れていないかは分かりますか。

どちらも分かりません。いずれも形式そのものの性質です。TZif ファイルは名前を持たず、ゾーンの同一性はデータベース内のパスだけから来ます。だから Asia/Istanbul のようなリンクは Europe/Istanbul と 1 バイトまで同じコピーかシンボリックリンクであり、内容では区別できません。できるのは略称・オフセット・遷移の日付という指紋からゾーンを見分けることで、ここの表はそのためにあります。形式にはチェックサムがどこにもないため、遷移表の 1 バイトが化けてもファイルは無効にならず、遷移が静かにずれるか別のタイプを指すだけです。検出できるのは長さがカウントと合わない場合だけで、このツールはそれを切り詰めとして拒否します。

関連ツール