884.txt

[1] [[計算機システム]]などの[[日時の処理]]では、
[[日時構成要素]]の値が取り扱い可能な 
[WEAK[(当初設計時に想定した)]]
[[値域]]を超えることがあり、問題となります。

[EG[
[40] 
例えば[[年]]の[[値域]]が 
[ [N[1900]], [N[1999]] ]
のとき、
[[年]]の値を
[N[2000]]
としたくなると、[[問題][Y2K]]が起こります。
]EG]

[18] 設計時の想定では遠い[[将来の日時]]だったとしても、
思いの外そのシステムが長生きするのはよくあることです。

[19] 逆パターンで[[値域]]の[[下限]]を超えることはそれほど多くありませんが、
想定よりも応用が広がり、[[過去の日時]]の記述の必要が生じるという可能性もなくはありません。

-*-*-

[38] 
情報交換用[[日時形式]]にせよ、情報処理用[[日時データ型]]にせよ、
実用上は[[日時]]の記述に使うデータサイズに制限を設けざるを得ません。
制限を取り払ってどれだけでも[[過去の日時]]や[[将来の日時]]を表現可能にすると、
[[RFC 2550の日時形式]]のような扱いづらい形式になってしまいます。

[EG[
[39] [[CPU]] や[[プログラミング言語]]の[[整数型]]が64ビットの場合、
それより大きな[[整数]]を扱うには特別な処理が必要となります。
[[日時]]を大きな[[整数]]で扱うと、
近い日時の計算も含めてすべての[[日時]]計算が煩雑で低速になってしまいます。
]EG]

[22] 
[[2000年問題]]への対処も、よくて9999年まで問題を先送りできたに過ぎませんでした。
実際には数十年程度の先送りで延命させたシステムも少なくありませんでした。
桁溢れ問題への本質的な対処は困難です。

* 呼称

[48] 
[[西暦2000年問題]]がこの種の問題では最も有名で、
[TIME[西暦2000年][2000]]以外でも[[代名詞]]的に使われることがよくあります。

[EG[
[51] 
[[昭和100年問題]]や[[民国100年問題]]が[[西暦2000年問題]]のようなものと紹介されます。
]EG]

[EG[
[50] 
[[Unix time]] の[[西暦2038年問題]]が
[[Unix Millennium 2038 Bug]]
と言われることがあります。
]EG]


[49] 
[[English]] ではしばしば [DFN[rollover]] と表現されます。
[[桁溢れ]]の結果[[最大値]]を超えて [N[0]] や最小値に戻る
([N[99]] から [N[0]] に戻る、 [N[2[SUP[32]]]] - [N[1]] から [N[0]] に戻る、
[N[2[SUP[31]]]] - [N[1]] から [N[-2[SUP[31]]]] に戻る、など)
ことを指していると思われます。

* 年の桁溢れ

[5] 発症パターンとして、

- [13] [[値域]]の[[上限]]を超えて問題が起きる
- [6] 下2桁で扱っていたので、100年目に問題が起きる
- [7] [VAR[n]]年から99年を前世紀、0年から[VAR[n]]-1年を新世紀として扱っていたので、
二度目の[VAR[n]]年付近で問題が起きる
- [9] 0年や99年を特別な意味で使っていて問題が起きる
- [20] [[整列]]の順序がおかしくなる

... というのがあります。

[34] 
[[データ型]]レベルの[[値域]]限界に達することもあれば、
[[日時入力]][[バリデーション]]の制限に達するケースもあります。


[FIG(short list)[ [10] [[年号]]の[[桁溢れ]]の問題
- [[DATE75問題]]
- [[OS/8の日時]]の限界
- [[2000年問題]]
- [[10000年問題]]
- [[昭和100年問題]]
- [[民国100年問題]]
- [[2061年問題]]
- [[2700年問題]]
- [[平成100年問題]]
- [[複数紀元詰め込み]]の問題
]FIG]

* 元号コードの桁溢れ

[2] [SEE[ [[元号コード]] ]]

* 整数時刻系の桁溢れ

[FIG(short list)[ [3] [[整数時刻系]]および[[時間]]変数の[[桁溢れ]]
- [[西暦1989年問題]]
- [[Deep Impactの日時]]
- [[2036年問題]]
- [[2038年問題]]
- [[49.7日問題]]
- [[497日問題]]
- [[24.9日問題]]
- [[248日問題]]
- [[512k日問題]]

]FIG]

-*-*-

[8] [[2010年問題]]、[[2020年問題]]、[[2021年問題]]のようにその他の[[値域]]制限に起因する場合もあります。

[37] 
[[Samsung]] SGH-C170
等
[[Agere]] チップセットを使った[[携帯電話]]は、
[ [TIME[1998-01-01]], [TIME[2014-12-31]] ]
の[[日付]]しか扱えず、
[TIME[2015-01-01]]以降に正常動作しなくなったとされます。
[SRC[>>36]]
これについての情報は少なく、 [CITE[Wikipedia]] も要出典としています。
[[掲示板]]の当時の書き込みで異常動作が報告されています [SRC[>>35]]。


[REFS[
- [35] [CITE@en-US[Samsung C170 - User opinions and reviews - page 2]], [TIME[2023-01-01T11:56:49.000Z]] <https://www.gsmarena.com/samsung_c170-reviews-2010p2.php>
- [36] [CITE@en[Time formatting and storage bugs - Wikipedia]], [TIME[2022-12-28T01:04:23.000Z]], [TIME[2023-01-01T11:57:00.150Z]] <https://en.wikipedia.org/wiki/Time_formatting_and_storage_bugs#Year_2015>
]REFS]

[47] [CITE[Wayback Machine]], [TIME[2023-11-25T11:47:07.000Z]] <https://web.archive.org/web/20080209230400/http://libsnap.dom.edu/ClasPlus/ADDONS/Y2K.TXT>

>[SNIP[]]16 binary bits are dedicated to
storing information representing years since the year AD 1. Folio's date
storage will rollover in the year 65,536.


* 循環型日時系の一周

[14] [[干支]]、[[GPS時]]など同じ名前の[[日時]]が一定期間経過後に繰り返される[[日時形式]]では、
当然ながら一周する期間を超えた範囲を扱うと[[日時]]を一意に識別できなくなります。

[EG[
[17] [[昭和]]は64年まであったため、
[[元号]]と[[干支]]だけでは[[年]]を一意に特定できません。
]EG]

[15] [[2000年問題]]や
[[100年問題]]もこの一種とも言えます。

* 整列

[4] 狭義の[[桁溢れ]]以外に、同じ[[桁]]数と仮定して[[文字列]]として[[整列][日時の整列]]させていたとき、
前提が崩れて順序がおかしくなるという問題が生じる場合もあります。

* その他

[11] 
解釈の曖昧性が発生する[[賞味期限表示]]の[[2020年問題]]があります。

[24] 
[[グレゴリオ閏日]]に関する[[2100年問題]]があります。

[46] 
事情がよくわからないものなど:
[[西暦2080年問題]],
[[西暦2100年問題]]


* 日時処理はどう設計するべきなのか

[25] 
[[西暦2000年問題]]が深刻な社会問題となっていた頃、
それは古い[[計算機]]の資源が乏しかった故のやむを得ない制約だとか、
先見性のない技術者の落ち度だとかいろいろ言われていました。
[SEE[ [[西暦2000年問題]] ]]

[26] 
[[西暦2000年問題]]の対策にはいろいろな手法がありました。
最も正当的とされた方法は[[年]]を2桁から4桁に変更するというものでした。
他に2桁のまま閾値を設けて1900年代か2000年代か切り分けたり、
[[西暦2桁年号]]のかわりに[[元号]]や[[皇紀2桁年号]]を使ったりする手法もあり、
特に前者は手軽な対策として相当広範囲で採用されたのですが、
それは場当たり的で解決を先送りしただけの、
悪い対策手法だという非難もありました。

[27] 
そんな時代に風刺的に話題になったのが[[西暦10000年問題]]でした。
[[西暦2000年問題]]の対策で[[年]]を4桁化したところで、
所詮それも解決を西暦9999年まで先送りしたに過ぎないのです。
そんな先の時代まで今のシステムが動き続けるとは思えないでしょうか。
でもそれこそが、[[西暦2000年問題]]を引き起こした怠惰で先見性のない技術者達の判断ではなかったのでしょうか。
問題を本質的に解決するためには、
4桁化ではなく無限の[[未来][未来の日時]]まで扱えるような改修をしなければならないのではありますまいか。


[28] 
現実的に考えて、
無限の[[過去][過去の日時]]から無限の[[未来][将来の日時]]まで、
無限の[[精度][秒の小数部]]で記述できる[[日時形式]]と[[日時処理]]システムというものは、
[[実装]]不能です。

[29] 
従って設計者はそのシステムの用途から実用上十分な[[値域]]と[[精度]]を考えて決める必要があります。
そしてその[[値域]]の限界に到達しそうなときにどのような対策を取るか、
少なくても対策を取り得る余地くらいは予め供えておく必要があるでしょう。


[30] 
そしてその意図を明確に言語化し、
後進の技術者達に伝承したり、
発注者に報告したりしなければなりません。

[31] 
少なくてもそれはその当時の技術的制約とアプリケーションの要求から導かれた妥協点であったはずです。
それを受け継いだ人々は、[[技術的負債]]などの陳腐な言葉で侮辱することなく、
現に稼働するシステムと真摯に向き合うべきです。




[33] 
現実には[TIME[西暦2000年][2000]]前後に既にその先十数年程度で不具合を生じるプログラムが公開、販売されていたことが知られています。
[SEE[ [[西暦2000年問題]] ]]



* 関連

[21] [[旧暦2033年問題]]は性質が異なります。

* メモ


[FIG(quote)[
[FIGCAPTION[
[12] [CITE@ja[SHARP社製一部携帯電話をご利用中のお客さまへ大切なご案内 | スマートフォン・携帯電話 | ソフトバンク]]
(掲載日:2015年10月9日 最終掲載日:2016年1月14日 [TIME[2020-01-02 22:13:34 +09:00]])
<https://www.softbank.jp/mobile/info/personal/news/product/20151009a/>
]FIGCAPTION]

> カレンダー(日時設定)の機能制限により 2016年1月1日(金)以降日時表示が正しく表示できなくなります。2016年1月1日(金)以降も正しい日時表示でのご利用を希望されるお客さまは、機種変更されることをお勧めいたします。
> 2016年1月1日(金)以降、発着信履歴およびメール送受信時間等の時刻表示も正しく表示できなくなります。

]FIG]


[FIG(quote)[
[FIGCAPTION[
[16] [CITE@ja[ケータイ電話のカレンダーの果てはどこまで? - エキサイトニュース]],
2009年8月20日 10:00,
[TIME[2020-11-28T05:12:19.000Z]]
<https://www.excite.co.jp/news/article/E1250562393684/>
]FIGCAPTION]

> 私のケータイのカレンダーは「2060年12月31日」までとなっている。あと51年!? は使える。一方、友人のカレンダーは「2030年12月31日」まで。差があるものだなーと思い、周りに聞いてまわったところ、以下のようになった。
> 2015年12月31日(SoftBank 912T)
> 2020年12月31日(au W61CA)
> 2030年12月31日(SoftBank 822SH)
> 2037年12月31日(Docomo SO705i)
> 2037年12月31日(Docomo P705i)
> 2060年12月31日(Docomo F882iES)
> 2099年12月31日(SoftBank 810P)
> 2099年12月31日(au mediaskin)
> 2099年12月31日(au W51SH)
> 9999年12月31日(au W64T)
> 9999年12月31日(au W54SA)

>
ケータイのカレンダーの長さに関して、Docomo・au・Softbankの三キャリアに質問メールを送ってみたが、おおむね「各端末メーカーの仕様になるので」という理由から、回答をいただくことができなかった。
>
では、と各メーカーに質問してみても、「各通信会社様がお問い合わせの窓口になりますので……」と、たらい回し状態。変な質問でお手数をかけ、申し訳ありませんでした。

>また、9999年までカレンダーが用意されている「超未来ケータイ」に関して、反対に気になったのが「始まりはいつなのか」という点。ひょっとして紀元1年とか…? 試してみると、1582年11月1日からカレンダーが始まっていた。

]FIG]

[23] この記事の筆者は「変な質問」と謙遜しているが、
製造・販売している側は答えられて当然の基本中の基本の仕様のはず。
それすらまともに答えられないのだから、
[[2020年問題]]や[[2021年問題]]を引き起こすのは必然だったということだ。

-*-*-

[32] [CITE@ja[Exchange Server、新年早々「2201010001」を long に変換できないエラー | スラド デベロッパー]], [TIME[2022-01-03T12:20:16.000Z]] <https://developers.srad.jp/story/22/01/03/085228/>


>
Microsoft によると「2201010001」はマルウェアスキャンエンジンで使用するシグニチャファイルのバージョンだという。バージョンの先頭 6 桁は YYMMDD であり、2021年までは問題なかったものの、2022年の日付のバージョンでは long (int32) の最大値 2,147,483,647を超えて問題が発覚したようだ。

- [42] [CITE@en[Time formatting and storage bugs - Wikipedia]], [TIME[2023-11-24T03:13:21.000Z]], [TIME[2023-11-25T06:51:13.925Z]] <https://en.wikipedia.org/wiki/Time_formatting_and_storage_bugs#Year_2022>
- [43] [CITE@en-US[Exchange Year 2022 Problem: FIP-FS Scan Engine failed to load – Can’t Convert “2201010001” to long (2022/01/01 00:00 UTC) | Born's Tech and Windows World]], [[guenni]], [TIME[2023-11-25T06:51:29.000Z]] <https://borncity.com/win/2022/01/01/exchange-fip-fs-scan-engine-failed-to-load-cant-convert-2201010001-to-long-1-1-2022/>
- [44] [CITE@en[Remember the Y2K bug? Microsoft confirms new Y2K22 issue | Science & Tech News | Sky News]], [TIME[2023-11-25T06:52:13.000Z]] <https://news.sky.com/story/remember-the-y2k-bug-microsoft-confirms-new-y2k22-issue-12507401>

[45] [[日時処理]]のための[[年]]ではなく、[[日付]]を転用した[[版番号]]の処理という変化球。


-*-*-

[41] [CITE@ja[292277026596年問題 - アンサイクロペディア]]
([TIME[2023-07-11T21:45:44.000Z]], [TIME[2023-08-09T02:07:13.138Z]])
<https://ja.uncyclopedia.info/wiki/292277026596%E5%B9%B4%E5%95%8F%E9%A1%8C>