将来の日時

将来の日時

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

暦法

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

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

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

紀年法

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

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

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

標準時

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

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

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

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

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

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

[47] tzdata夏時刻について最新の実施状況から規則性を推定し、 少なくても直近数ヵ年分はそのまま適用されると仮定しています。 この推測は外れることもあり、適宜修正されています。

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

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

時刻系

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

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

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

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

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

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

閏秒

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

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

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

日時形式

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

文脈

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

実装

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

[49] 日本の元号を使った表記は、定期的に改元される前提で運用されてきました。 当然のことながら情報システムもそれを織り込んで設計、運用されなければなりません。

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

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

[50] できるだけ低コストで対応したいものですが、 予測不能な将来の改暦に対応可能にするのは困難、 あるいは不可能でしょう。

[51] 50年以上夏時刻が実施されていない国でのみ使われるシステムで夏時刻に対応するメリットは何もありません。 ある日突然夏時刻が実施されることになれば、大改修は必至です。

[52] 太陽の寿命が近づき人類が新天地に移住した時、 地球暦法は新生活に不便なので、 改暦されるに違いありません。 それはいったいどんな暦法でしょうか。 それを今から織り込んでおくのは不可能です。

[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年のような大きな値の日時を与えると、異常に時間がかかります。 日時計算ソフトウェアのパフォーマンス問題

[48] 利用者に不便を与えるだけでなく、 セキュリティー問題となる可能性もあります。 日時のセキュリティー

関連

[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

[10] [tz] DST ends 2040 in Oracle database () https://mm.icann.org/pipermail/tz/2019-January/027444.html

[204] Storing UTC is not a silver bullet – Jon Skeet's coding blog () https://codeblog.jonskeet.uk/2019/03/27/storing-utc-is-not-a-silver-bullet/amp/

[45] How to save datetimes for future events - (when UTC is not the right answer) () http://www.creativedeletion.com/2015/03/19/persisting_future_datetimes.html

[53] 61世紀 :: 年代 :: 東文研アーカイブデータベース, https://www.tobunken.go.jp/materials/nkera/61%e4%b8%96%e7%b4%80

「年代別」 欄を見ると、 「07世紀」 から 「19世紀」 のほかに、 「61世紀 (1) 66世紀 (1) 67世紀 (1) 68世紀 (1) 69世紀 (1) 70世紀 (1) 72世紀 (1) 75世紀 (1) 92世紀 (1) #VALUE! (1)」 があります。括弧内は件数を表します。

[54] この謎の61世紀から92世紀のデータを見ると、 「推古天皇14年・天智天皇5年 (0606)」 のようにあって、 3桁西暦年の上2桁から誤って西暦世紀を計算したものとわかります。

このデータベースは 「『日本絵画史年紀資料集成 十―十四世紀』(1979年)、『日本絵画史年紀資料集成 十五世紀』(2011年)に採録された年紀資料にもとづきつつ、さらに資料の収集をすすめたうえで、作品名・所蔵者名・銘文などの各項目内容から検索ができるように整えたもの」 >>53 だといいます。 すると「さらに」収集したものから誤った世紀情報が混入したものと推察されます。

「#VALUE!」 に登録されている資料の年次は 「文政5年 () 」 とあって、 西暦年の登録が抜けております。 つまり他のデータの世紀はこの西暦年から計算されたものとみられます。 正しく登録された7世紀から10世紀の資料の西暦年とも外見上違いが見られないので、 データベース上には計算済みの西暦世紀が保存されていて、 そのうちいくつかは間違っていて、いくつかは正しいのでしょうか。

[55] この種の間違いはないでもないので、 ふつうわざわざ問題とするほどのことでもないのですが、 「より質の高い資料の提示が求められる昨今の時勢に対応し」 て制作されたという国立研究所の成果物が、 Webページを1回見て確認すれば誰でも気づかないはずのない間違いを含んだまま放置されているのは、 どうなんでしょうね。

[56] Internet Archive をみると: 年紀資料集成 :: 東文研アーカイブデータベース, https://web.archive.org/web/20200502224525/https://www.tobunken.go.jp/materials/nenki平成31年時点ではまだおかしなデータはみられなくて、 令和2年から変なデータが入っているので、 比較的最近追加されたデータがおかしな処理を経ているのでしょう。

[57] PlayPic - 重要なお知らせ (, ) https://playpic.jp/campaign/8

PlayPicの動画データに関してDMM TVにて引き続き視聴いただける環境を構築してまりいますが、一部作品は提供を終了するため「視聴期限:9999/12/31」であっても2023年7月31日(月)をもってご利用いただけなくなります。