[1] まだ到来していない日時は不安定で不確実です。 が、将来の日時を取り扱うことも、よくあります。
[2] グレゴリオ暦は機械的に日付を定めているので、無限の先まで日付を確定できます。 これはグレゴリオ暦の大きな特徴となっています。
[3] 他の多くの暦法は、遠い将来の日付が確定できません。 天体観測によってその年の暦が定められるので、 現在から遠く離れるほど、予測精度は下がっていきます。 蒙古暦のように、最終的に人間の判断で確定させられる暦法もあります。
[5] 西暦や皇紀などは機械的に年数を定めているので、無限の先まで年を確定できます。
[6] 元号は、改元がいつ行われるかまったく予測できません。 元号を使う場合、将来の日付は実際にその時点では利用されない可能性が高い (そして現に利用されなかった) 元号で記述されることがよくあります。 改元の際に訂正されることもあれば、そのまま残されることもあります。
[11] 標準時は、改正される可能性があります。 地球全体で見れば、ほとんど毎年どこかの地域で標準時が変更されています。
[12] 夏時刻の実施の有無や時期は、頻繁に改正されています。 実施の月日が毎年自動的に決まる地域もありますが、 そうでない地域がたくさんあります。
[13] こうした変更は人間の判断によるものですから、まったく予測できません。 変更の実施直前に突然発表されることもあります。
[8] 閏秒は地球の自転速度を踏まえて人間の判断によって実施されます。 いつ実施されるかは予測できません。
[9] 将来の日時を高い精度で記述したとしても、 現在からの距離は閏秒によって秒単位でずれていきます。
[21] 「今から1億秒後」がいつのことなのかは、変わるかもしれません。
[19] 実際、世界時や秒の定義は過去に数回改正されています。
[20] 極めて高い精度が求められる専門分野を除けば、大きな影響が生じる変更が加えられる可能性は低いと思われます。 しかし、閏秒の廃止が検討されていたりして、将来どのような変更が行われるかは予測しきれません。
[7] 日時の記述に用いる形式やデータ型が、 現在から遠く離れた日時を記述できないことがあります。
[17] 計算機システムなどで日時を扱う場合、 将来の日時の体系の変更にある程度自動的に追随できる仕組みを作っておく必要があります。
[22] 将来の日付の扱いは面倒です。将来行われうる暦法の変更を我々は知り得ないからです。
おそらく最も現実的な解は、
[23] また、情報記録用の形式に通し時 (Un*xtime やユリウス日など) ではなく ISO 8601 のような人間可読形式を採用するのも良い考えかもしれません。 2003年1月1日の (365*100+閏日の数) 日後が2103年1月1日になる保証はありませんからね。
[28] 将来閏日が増えたり減ったり、あるいは時の為政者が2月30日を作るとか言い出したらどうでしょう? 理論上は閏日の調整はグレゴリオ暦で数万年は狂わないそうですけど、後者はあり得るかも。なんにせよ、将来のことは分からない。だから例えば、 10000-02-31 みたいなデータは、もし処理系に余裕があるなら、内部形式に変換して外部形式に再変換した時にも 10000-02-31 に戻ってくるのがいい気がします。まあ実際にはそんなこと考えてもいられないでしょうし、考える必要もあまりないでしょうけど。
[24] Microsoft Office Outlook 用タイム ゾーン データ更新ツールを使用してタイム ゾーンの変更に対処する方法 () <https://support.microsoft.com/ja-jp/help/931667/how-to-address-time-zone-changes-by-using-the-time-zone-data-update-tool-for-microsoft-office-outlook>