601.txt

[1] まだ到来していない[[日時]]は不安定で不確実です。

* 暦法

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

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

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

* 紀年法

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

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

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

;; [[元号]]参照。

* 標準時

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

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

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

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

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

* 閏秒

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

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

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

* 時刻系

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

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

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

* 日時形式

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

;; [[2000年問題]]、[[10000年問題]]などを参照。

[10] [[2桁西暦年号]]や[[GPS時]]のように、[[現在]]の前後のある程度の限られた時期しか記述できない方式もあります。

* 実装

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

;; [[ロケール]]のデータの項を参照。


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

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

* 関連

[29] [[過去の日時]]も参照。

* メモ

[24] [CITE@ja-jp[Microsoft Office Outlook 用タイム ゾーン データ更新ツールを使用してタイム ゾーンの変更に対処する方法]]
([TIME[2017-01-26 22:11:41 +09:00]])
<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>