Edit

Page

Page title:

Page body:

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

* 暦法

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

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

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

[EG[

[61] 
最近はあまり聞かなくなりましたが、20世紀には[[暦法改良案]]各種が世界各国で盛んに議論され、
[[グレゴリオ暦]]にかわる新暦の導入が検討されていました。

]EG]

* 紀年法

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

-*-*-

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

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

[58] 
厳密に言えば[[延長年号]]は「存在しない年の表記」になるのではなく、
「最適な年の表記ではない年の表記」になります。

[EG[

[59] 例えば「平成32年」と「令和2年」はどちらも「存在」していて、
同じ年を指しています。[[令和改元]]によって「令和2年」が
「最適な年の表記」に変わりましたが、「平成32年」も存在はし続けています。

[60] 
これに対して「令和6年6月6日 6時6分'''60秒'''」は「存在しない秒の表記」です。

]EG]

* 標準時

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

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

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

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

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

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

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

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

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

* 時刻系

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

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

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

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

** 秒

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

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

** 閏秒

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

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

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

* 日時形式

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

* 文脈

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

[FIG(list middle)[
- 予定管理ソフトウェアにおける予定の日時
- イベントの開催日時
- [[番組]]の放送予定日時
- 組織の中長期計画における日付
- [39] 航空券の予約における発着日時
- [[切符]]の有効期間の開始と終了の日時
- [40] 借金返済の日時
- [41] 会議室利用予定の日時
- [42] 食品の[[賞味期限]]
- [43] [[キャッシュ]]の[[有効期限]]
- [44] [[証明書]]の[[有効期限]]
- [46] [[SNS]] への予約投稿の[[日時]]
- [[暦本]]における[[日時]]
]FIG]

* 実装

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

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

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

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

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

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

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

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

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

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

* 関連

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

[204] [CITE@en[Storing UTC is not a silver bullet – Jon Skeet's coding blog]]
([TIME[2019-04-05 03:41:10 +09:00]])
<https://codeblog.jonskeet.uk/2019/03/27/storing-utc-is-not-a-silver-bullet/amp/>

[45] [CITE[How to save datetimes for future events - (when UTC is not the right answer)]]
([TIME[2019-01-10 03:54:59 +09:00]])
<http://www.creativedeletion.com/2015/03/19/persisting_future_datetimes.html>

[53] 
[CITE@ja[61世紀 :: 年代 :: 東文研アーカイブデータベース]], [TIME[2020-06-07 10:28:56 +09:00]] <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)」
があります。括弧内は件数を表します。
[TIME[2020-06-07T01:30:31.300Z]]

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

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

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

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

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

[FIG(quote)[
[FIGCAPTION[
[57] [CITE@ja[PlayPic - 重要なお知らせ]]
([TIME[2023-04-03T00:34:06.000Z]], [TIME[2023-04-03T06:48:05.595Z]])
<https://playpic.jp/campaign/8>
]FIGCAPTION]

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

]FIG]

Historical Legal Sensitive Parent: [Help / License]

Edit

Page

Errors

Page name(s)