将来の日時

将来の日時

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

暦法

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

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

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

紀年法

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

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

[16] 北海道新幹線新函館北斗札幌間は度開業予定とされています。 しかし平成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] 日時の記述に用いる形式データ型が、 現在から遠く離れた日時を記述できないことがあります。

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

実装

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

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

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

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

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


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

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

関連

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

メモ

[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