過去の日時

[34] 過去の日付の取扱いは茨の道です。
[35] 多くの処理系が採用している Un*x時間は、 TheEpoch (1970-01-01T00:00:00+00:00; 0) 以前が扱えません。 (一部、負の値を使って扱えるように拡張している実装もありますが。)
[36] そして、 >>35 の問題が解決したとすると、次にましますは暦の問題です。グレゴリオ暦改暦以前はユリウス暦として扱わなければなりません。
[37] >>36 しかも改暦は国・地域により異なります。
[38] >>36-37 日本の場合はグレゴリオの前は天保暦 (太陰太陽暦) だったりします。
[39] で、それ以前となると、国・地域ごとに暦はばらばら、暦の運用も不規則 (理論上の閏とかを運用してなかったり。)、時代が遡ると詳細不明だったり、ということで、過去の日付の処理の実装はいかに暦データベースを上手く実装するか、ということになりそうです。
[42] 実際に扱えるようになったら、その環境で入力されたデータは改暦を考慮したか否かとかでぐちゃぐちゃになりそう。実際に巷で流れてる、例えば歴史的事項の日付がどういう暦での日であるのかは明記されないことが普通だし。

先発暦

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

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

[4] 先発暦

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

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

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

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

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

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

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