過去の日時

過去の日時

[47] DCMI Date Working Group http://www.dublincore.org/groups/date/

先発暦

[3] 便宜上、現行を過去に延長した暦法を使うことがよくあります。

[59] 計算機処理では、グレゴリオ暦を過去に延長した先発グレゴリオ暦先発UTCを用いることが多いです。

[4] 先発暦

過去情報修正による変化

[86] tzdata は過去のデータも資料の発見に基づきしばしば改訂されています。 過去の歴史的事象の記述のために当地で記録されている日時を現在の当地の時間帯に基づき先発UTCに変換して保持していると、 後から tzdata が改訂された時に、元の想定とは違う値に変化してしまうことがあります。

[87] 例えば時間帯 R/S で西暦1234年の時差+01:23 と定義されていたとします。 の出来事を記録するため、 1234-05-06T00:00:00+01:23 すなわち 1234-05-05T22:37:00Z という先発UTCの値を使うことにします。 表示の際に、 R/S に変換して日付だけ取って とします。

その後、 R/S の西暦1234年の時差+01:20 に変更された時、 この値は 1234-05-05T23:57:00+01:20 ですから、 日付だけ使うと になり、1日ずれてしまいます。

[89] 時間帯の分割などがあると、 tzdata でも新たな識別子が追加されます。 tzdata を使うプラットフォーム利用者は新設時間帯に属するなら、 新しい識別子に設定を変更することになります。 すると過去の日時について、同様の“変化”が起こることになります。

日時形式

[7] 日時の記述に用いる形式データ型が、 現在から遠く離れた日時を記述できないことがあります。 日時桁溢れ問題

ロケールデータベースの限界

[1] tzdata は、 (Unix Epoch) 以前に対応していません。 より正確に言えば、 以前の情報も (積極的にではありませんが) 収集していますが、 以前のみ他と異なることを根拠に別の時間帯として扱わない、 という方針を採っています。 tzdata

[2] CLDR以前のタイムスタンプを扱えません。 より正確に言えば、 何らかの形で扱われるようなデータは用意されていますが、 それを使って適切な結果が得られることは保証されません。 CLDR

関連

[19] 将来の日時暦の換算も参照。

メモ