601.txt

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

* 暦法

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

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

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

* 紀年法

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

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

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

* 標準時

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

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

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

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

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

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

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

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

* 時刻系

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

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

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

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

** 秒

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

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

** 閏秒

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

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

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

* 日時形式

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


* 実装

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


[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]] に戻ってくるのがいい気がします。まあ実際にはそんなこと考えてもいられないでしょうし、考える必要もあまりないでしょうけど。

-*-*-

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

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

* 例

[38] 次のような[[日時]]を扱う可能性があります。

- [39] 航空券の予約における発着日時
- [40] 借金返済の日時
- [41] 会議室利用予定の日時
- [42] 食品の[[賞味期限]]
- [43] [[キャッシュ]]の[[有効期限]]
- [44] [[証明書]]の[[有効期限]]

* 関連

[29] [SEE[ [[過去の日時]] ]]

* メモ

[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>

[10] [CITE['''['''tz''']''' DST ends 2040 in Oracle database]]
([TIME[2019-01-29 09:01:31 +09:00]])
<https://mm.icann.org/pipermail/tz/2019-January/027444.html>