要約

  • RFC 9636が標準化するのはTZifの表現であり、その中身を作った民用時刻規則の出所や最新版であることではない。
  • 32ビット互換ブロック、64ビット遷移表、切り詰め範囲、footer、version 4のうるう秒表期限が、計算結果の証拠範囲を決める。
  • 監査可能な記録には、意図、ゾーン、情報源と版、ファイルhash、対象期間、reader、曖昧さ処理、表示結果、実行結果が要る。

最後に保存された遷移までは表が答える。その次の瞬間からはfooterの規則が答える。この境界で値が連続していても、将来の制度が連続するとは限らない。

RFC 9636はRFC 8536を置き換え、互換性を保ちながらversion 4を加えたStandards Track文書である。対象は交換形式だ。TZifへ組み立てられたデータの出所は定義しない。IANA Time Zone Databaseは代表的な出所だが、魔法番号だけではIANA由来ともrelease番号とも分からない。

したがって「offsetを得た」という記録は短すぎる。どの地域を選び、どのreleaseのどのbytesを、どのreaderがどう解釈したかまで保存して初めて再現できる。

互換ブロックと本体は同じ答えを約束しない

TZifは必ずversion 1のheaderとdata blockから始まる。遷移時刻は32ビットで、1901年末から2038年1月までしか表せない。version 2以降は、その後ろに64ビットのheader、data block、footerを追加する。

古いreader向けの最初のblockはplaceholderでもよい。その場合、version-1-only readerは時制変更も略称もないものとして扱う。一方、現在のreaderは最初のblockを飛ばして64ビット表を使う。同じファイルを正常に開いた二つのプログラムが、同じ規則を読んだとはいえない。

記録にはformat version、readerの能力、実際に選んだblock、countとfile lengthの検証、hash、source releaseを含める。特に2038年以後の値で古い分岐を試験しなければ、互換性の成功が意味の失敗を隠す。

不明を明示するための切り詰め

遷移は昇順で並び、各時点から次の時点までlocal time typeを選ぶ。typeにはUT offset、DST flag、designation indexがある。最後の遷移より後は、空でないfooterがある場合だけその規則を使う。なければlocal timeは未指定だ。

TZDISTは用途に合わせて遷移表を切り詰められる。開始点より前を知らないファイルはtype 0を未指定にし、終了点より後を知らない例は-00と空footerで境界を示す。有効なファイルでも、全時代に完全とは限らない。

未指定をhostのdefault zoneや最後のoffsetで埋めるのは、readerではなく製品の方針である。その方針を使うなら、名前、version、適用理由、警告を別のreceiptとして残す必要がある。

footerは外挿規則である

footerのPOSIX形式文字列は、保存された最後の遷移以後を計算する。最後の遷移との境界で同じtypeになることが要求される。この整合性はファイル内部の性質で、政府が将来も同じ夏時間を採用するという証明ではない。

データベースが更新されたとき、未来の予定について何を維持するかを決めなければならない。元のinstantか、元のwall timeか、主催者の再確認か。zoneとreleaseを捨ててUTCだけ保存すると、その選択肢自体が消える。

略称も意図を復元しない。CSTは複数地域を表せる。同じoffsetを共有するzoneも後で異なる規則へ分岐し得る。zone identifierと選択経路は、計算値とは独立に必要だ。

version 4は知識の期限を表す

version 4では、うるう秒記録を先頭で切り詰め、最後の記録でtable expirationを示せる。期限より後は、次の補正があるかないかをtableが保証しない。

readerは期限後を拒否してもよいし、期限を無視して計算を続け、errorを示してもよい。どちらも仕様上の選択になり得るが、同じ信頼度ではない。「計算済み」と「有効期間内」を別の状態にする必要がある。

第27回CGPM決議4はうるう秒の将来を扱う。しかし、ある端末がどの表をloadし、期限を見てどのbranchを実行したかまでは証明しない。制度、配布物、running codeを一つの事実にまとめてはいけない。

配布のTLSと意味の鮮度

TZif自身はintegrityもconfidentialityも提供しない。counted arrayの長さとindexは実ファイル内に収まるか検証すべきで、TZifという4 octetだけでは足りない。公開経路での配布にはTLSなど外部保護が必要だ。

ただしTLSは一回のchannelを保護する。serverが意図したreleaseを選んだか、ETagが新しいか、cacheが更新されたか、local fileが後で置換されなかったかは別問題である。source、release、URL、ETag、取得時刻、hash、cache age、install結果を結ぶ。

zone取得は利用者の過去・現在・未来の場所を示す可能性もある。規則が公開情報でも、選択履歴まで公開してよいとは限らない。

readerの結果から業務結果へ

RFC 3339はoffset付きinstantを表せる。RFC 9557はzone名など追加情報を付けられる。RFC 5545はcalendar objectを扱う。それでも、利用したTZifのhash、release、曖昧時刻の方針は自動的には入らない。

時計を戻すと同じwall timeが二度現れ、進めると存在しない時刻が生じる。遷移表は候補を示すが、早い方、遅い方、shift、reject、確認のどれを選ぶかはapplication authorityである。そしてjobが実際に起動したかはさらに次のreceiptだ。

完全な鎖は、民用時刻の意図、zone選択、source release、artifact、reader policy、変換結果、application decision、observed effectを分ける。RFC 9636はbytesの意味を統一するが、明日の法律や人の意図を代行しない。

出典