将来の日時

[1] まだ到来していない日時は不安定で不確実です。が、将来の日時を取り扱うことも、よくあります。

暦法

[2] グレゴリオ暦は機械的に日付を定めているので、無限の先まで日付を確定できます。これはグレゴリオ暦の大きな特徴となっています。

[3] 他の多くの暦法は、遠い将来の日付が確定できません。天体観測によってその年の暦が定められるので、現在から遠く離れるほど、予測精度は下がっていきます。蒙古暦のように、最終的に人間の判断で確定させられる暦法もあります。

[4] 改暦の可能性はいつでもあります。人間の判断によるものですから、まったく予測できません。

紀年法

[5] 西暦や皇紀などは機械的に年数を定めているので、無限の先まで年を確定できます。

[6] 元号は、改元がいつ行われるかまったく予測できません。元号を使う場合、将来の日付は実際にその時点では利用されない可能性が高い (そして現に利用されなかった) 元号で記述されることがよくあります。改元の際に訂正されることもあれば、そのまま残されることもあります。旧元号表記の日付も、法的には有効とされています。元号、改元

[16] 北海道新幹線の新函館北斗・札幌間は平成42年度開業予定とされています。しかし平成31年に改元されると噂されています。

標準時

[11] 標準時は、改正される可能性があります。地球全体で見れば、ほとんど毎年どこかの地域で標準時が変更されています。

[12] 夏時刻の実施の有無や時期は、頻繁に改正されています。実施の月日が毎年自動的に決まる地域もありますが、そうでない地域がたくさんあります。夏時刻

[13] こうした変更は人間の判断によるものですから、まったく予測できません。変更の実施直前に突然発表されることもあります。

[14] 将来の日時を記述したとしても、現在からの距離はずれていく可能性があります。

[15] 1年後のある月日について、「10時から会議」とスケジュールを登録したとします。翌年までに夏時刻の開始時期が変更されていると、「10時」が指している時刻が登録時点と当日とでずれている可能性があります。

[33] 体育館利用予約システムで「毎週17時から18時」の利用を登録したとします。登録前に夏時刻の期間が確定していない場合や登録後に夏時刻の期間が改正された場合でも、「登録時点で17時と考えられた時刻」や「登録した日の17時にそれまでの日数分 24 を加えた時刻」ではなく、「実際に当日に用いられることになった時刻での17時」が各週の予約開始時刻となるべきです。

[36] 将来の日時を、時間帯のない日時を時間帯との組み合わせで保持するのが、最も簡単な対処方法でしょうか。

[37] ある時点まで同じ標準時を共有してきた地域の一部が異なる標準時に移行することで時間帯が分割 (新設) されることがたまに (何年かに1回くらい) あります。この場合は時間帯をそのままにするか、新しいものに変更するかの判断が必要となります。

時刻系

[18] 時刻系は改正される可能性があります。

[19] 実際、世界時や秒の定義は過去に数回改正されています。

[20] 極めて高い精度が求められる専門分野を除けば、大きな影響が生じる変更が加えられる可能性は低いと思われます。しかし、閏秒の廃止が検討されていたりして、将来どのような変更が行われるかは予測しきれません。

[32] 精度が必要ない分野では、閏秒のない時刻系を用いるのが便利と考えられています。

秒

[34] SI秒や (現在においてはそれと等しい) 暦秒の長さは、何度か定義が正確に改められました。これからも予期せぬ将来のいずれかのタイミングで改正される可能性があります。

[35] ほとんどの場合に秒は固定の長さとして扱い、秒より短いミリ秒やマイクロ秒なども秒を単純に十進法で分割した長さとしていますが、厳密な時間の長さが問題となる場面では、そうした仮定が成立しないこととなります。

閏秒

[8] 閏秒は地球の自転速度を踏まえて人間の判断によって実施されます。いつ実施されるかは予測できません。

[9] 将来の日時を高い精度で記述したとしても、現在からの距離は閏秒によって秒単位でずれていきます。

[21] 「今から1億秒後」が日付でいうといつのことなのかは、変わるかもしれません。

日時形式

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

実装

[17] 計算機システムなどで日時を扱う場合、将来の日時の体系の変更にある程度自動的に追随できる仕組みを作っておく必要があります。ロケールの更新

[22] 将来の日付の扱いは面倒です。将来行われうる暦法の変更を我々は知り得ないからです。おそらく最も現実的な解は、

年月日のように簡単に仕組みが変わりそうにないものは、とりあえず現在の法則が適用されると仮定し、出来るだけ長くその方法で使えるようにする。 (実質的には、年の数が大きくなっても扱えるように、ということ。)
閏秒や時間帯 (特に夏時刻) のように頻繁に変わり得るものは、プログラムの外部の設定ファイルを参照するなどして簡単に修正可能にしておく。

... ことくらいでしょうか。

[23] また、情報記録用の形式に通し時 (Un*xtime やユリウス日など) ではなく ISO 8601 のような人間可読形式を採用するのも良い考えかもしれません。 2003年1月1日の (365*100+閏日の数) 日後が2103年1月1日になる保証はありませんからね。

[25] 2000年問題: 既に過去になってしまった、将来の日付の問題。
[26] 10000年問題: まだ遠い将来である、将来の日付の問題。
[27] Un*x時間: 32ビット整数桁溢れ問題 (いわゆる2038年問題)

[28] 将来閏日が増えたり減ったり、あるいは時の為政者が2月30日を作るとか言い出したらどうでしょう? 理論上は閏日の調整はグレゴリオ暦で数万年は狂わないそうですけど、後者はあり得るかも。なんにせよ、将来のことは分からない。だから例えば、 10000-02-31 みたいなデータは、もし処理系に余裕があるなら、内部形式に変換して外部形式に再変換した時にも 10000-02-31 に戻ってくるのがいい気がします。まあ実際にはそんなこと考えてもいられないでしょうし、考える必要もあまりないでしょうけど。

[30] 日時に関わる計算は、日時の値に依存しない計算量で行えるものとするべきです。

[31] あるプログラミング言語用の日時処理ライブラリーは、日時オブジェクトの作成時に UTC と地方時の換算を行います。この時現在の夏時刻の規則を無限に将来に延長するため、現在から当該日時まで毎年の夏時刻の有無を検査します (本当はそんな検査などしなくても求められるはずですが...)。そのため、西暦6000年のような大きな値の日時を与えると、異常に時間がかかります。