要約

  • 当初のRFC 3339では、-00:00はUTC上の瞬間が既知でローカルオフセットだけが不明であることを示し、Zと+00:00はUTCを優先参照とした。RFC 9557は後に不明オフセットの意味をZへ与え、+00:00の意味は維持した。
  • 正規化後の瞬間が等しくても証拠は同じではない。生の文字、解釈プロファイル、オフセットの由来、小数精度、時計状態、うるう秒表、取得、アプリ結果は別々の受領証を必要とする。

新しい規則が古いバイト列を読み直す

厄介なのは、明らかな構文エラーではない。昔は正しく受理された文字列を、現在のライブラリが更新後の意味で読む場面である。計算される瞬間は同じでも、その表現が語る由来が変わる可能性がある。

RFC 3339の元の4.3節は-00:00を、UTC時刻は既知だがローカル時刻との差が不明な場合に割り当てた。Zと+00:00はUTCが優先する参照点であることを含意した。同じ秒を表せても、失われている情報についての主張は異なった。

由来はインターネットメールにある。RFC 2822とRFC 5322の-0000は、Universal Timeとして時刻を示しつつ、生成システムのローカルゾーン情報を持たないことを表す。いつかは分かるが、どのローカル関係から来たかは分からない。

相互運用性が意味の更新を促した

RFC 9557は負のゼロが抱えた問題を説明する。ISO 8601:2000以後は-00:00を認めず、未知のローカルオフセットを表したい実装はZを使う傾向があった。その実態に合わせ、RFC 3339の解釈が更新された。

現在の更新では、ZがUTC瞬間既知・ローカルオフセット不明を表せる。+00:00は更新されず、UTCが優先参照であるという意味を保つ。-00:00は正式に廃止されたわけではないが、代わりにZを使うことが推奨される。

したがって監査記録には、文字列と、それを解釈した規格・アプリの版が要る。瞬間だけを保存すれば由来が消え、文字列だけを保存しても、後年の規則で誤読され得る。

ただし文書の更新は実装の更新証明ではない。特定製品の挙動は、ライブラリ版、設定、配備時点、試験結果で示す必要がある。

オフセットはゾーン名ではなかった

RFC 3339の数値オフセットはローカル時刻からUTCを引いた関係である。その瞬間を変換するには足りるが、地域名、法域、夏時間規則、機器位置までは識別しない。

同じオフセットを共有する地域も将来は別の規則を採用し得る。RFC 8536のTZifは、遷移時刻、ローカル時刻型、表記、うるう秒補正を別のデータとして持つ。単一オフセットに含まれない情報である。

UTCへ変換すれば事象の並びを合わせられる。しかし導入済みゾーンデータの版、選択ゾーン、将来の民間時刻の意図は証明できない。設定とデータ版を結ぶ受領証が別に要る。

不明オフセットは浮動時刻ではない

「ローカルオフセット不明」は「瞬間不明」ではない。RFC 3339ではUTC上の瞬間が既知で、ローカルとの関係だけが欠ける。同文書は一般的なインターネット交換に無修飾ローカル時刻を使うことを、世界の大半で誤解されるとして退けた。

RFC 5545の浮動時刻は別の意図を持つ。参加者がどのゾーンにいても11時という予定は、同じ壁時計の値を保ちながら人ごとに別の実瞬間になり得る。

両方を一つの「タイムゾーン不明」状態へ押し込むと、不確かさの対象が消える。一方は瞬間を知り由来を知らない。他方は壁時計を知り、瞬間を文脈に委ねる。

文字列順序には同じ車線が必要だった

RFC 3339は、一定条件なら文字列比較で時間順になる利点を挙げた。条件は、同じタイムゾーン、同じゾーン表記、同じ小数桁数である。このいずれかが欠ければ保証外となる。

異なるオフセット、Zと+00:00、一桁と複数桁の小数を混ぜた一覧は、そのまま並べてよい集合ではない。基本ABNFは小文字tとzも許すが、利用プロトコルが大文字だけに狭めることもできる。検証済みerrataには編集上の修正や付録Aの訂正もあり、付録のISO収集文法を5.6節のインターネットプロファイルと同一視してはならない。

比較用の正規形を作ること自体は合理的である。ただし変換規則と原文を保存し、索引値を受信証拠と取り違えないことが条件となる。

小数の長さは時計の正確さではない

RFC 3339が残した稀な選択肢は秒の小数である。厳密な順序や特殊な精度のために使われ、桁数に上限は示されない。これは表現の細かさを述べるだけで、時計の正確さを認証しない。

同期されていない機器でも多数の桁を出せる。追跡可能な時計が整数秒だけを出す場合もある。RFC 5905が扱うNTPの階層、オフセット、誤差と同期状態は別の証拠面であり、日時文字列からは復元できない。

桁数、ハードウェア分解能、同期元、最終同期、不確かさ、取得経路を分離して保存する。ゼロを付け足しても観測は改善しない。

60秒目は外部の予定表を必要とした

RFC 3339は正のうるう秒が入る月末に秒値60を認め、負のうるう秒なら最大値が58になる可能性も扱う。構文だけでは、その日付に調整が実施されたか判断できない。

RFC 8536は版を持つデータの中にうるう秒補正とゾーン遷移を置き、RFC 5905は時計プロトコルの状態を提供する。したがって23:59:60を解析できたことは構文受理であり、日程の真正性ではない。

時間尺度によってうるう秒の数え方も異なる。異種ログを比べる前に、尺度、表、変換関数を残す必要がある。単一の整数へ潰すだけでは境界を隠してしまう。

タイムスタンプは出来事を認証しなかった

RFC 3339は書式を標準化したのであって、作成者、付与時点、署名範囲、行為の成立を証明しない。署名の隣にある時刻が署名対象外の場合もある。受信時刻は取得時刻と違い、誤設定時計も構文上正しい未来を作る。

耐久性のある受領証は、生文字列、解釈版、解析フィールド、派生瞬間、オフセット、時計証拠、不確かさ、ゾーンとうるう秒データ、格納物ハッシュ、暗号範囲、転送受信、アプリ結果を結ぶ。

この規格史が示すのは単純である。瞬間は同じでも、表現の由来は同じとは限らず、後の標準が読み方を変えることさえある。時間を比較する値と、その値を信じる根拠を一つに潰してはならない。

出典