[1] 計算機システムなどの日時の処理では、 日時構成要素の値が取り扱い可能な (当初設計時に想定した) 値域を超えることがあり、問題となります。
[18] 設計時の想定では遠い将来の日時だったとしても、 思いの外そのシステムが長生きするのはよくあることです。
[19] 逆パターンで値域の下限を超えることはそれほど多くありませんが、 想定よりも応用が広がり、過去の日時の記述の必要が生じるという可能性もなくはありません。
[67] 固定長データ等の一般の桁溢れ問題の一種ですが、 日時の場合は将来の日時の記述で問題が起こることが多く、 一定期間潜伏した後に特定の期日に大きな問題として発症しがちという特性があります。
[38] 情報交換用日時形式にせよ、情報処理用日時データ型にせよ、 実用上は日時の記述に使うデータサイズに制限を設けざるを得ません。 制限を取り払ってどれだけでも過去の日時や将来の日時を表現可能にすると、 RFC 2550の日時形式のような扱いづらい形式になってしまいます。
[39] CPU やプログラミング言語の整数型が64ビットの場合、 それより大きな整数を扱うには特別な処理が必要となります。 日時を大きな整数で扱うと、 近い日時の計算も含めてすべての日時計算が煩雑で低速になってしまいます。
[22] 2000年問題への対処も、よくて9999年まで問題を先送りできたに過ぎませんでした。 実際には数十年程度の先送りで延命させたシステムも少なくありませんでした。 桁溢れ問題への本質的な対処は困難です。
[48] 西暦2000年問題がこの種の問題では最も有名で、 以外でも代名詞的に使われることがよくあります。
[50] Unix time の西暦2038年問題が Unix Millennium 2038 Bug と言われることがあります。
[49] English ではしばしば rollover と表現されます。 桁溢れの結果最大値を超えて 0 や最小値に戻る (99 から 0 に戻る、 232 - 1 から 0 に戻る、 231 - 1 から -231 に戻る、など) ことを指していると思われます。
[5] 発症パターンとして、
... というのがあります。
[34] データ型レベルの値域限界に達することもあれば、 日時入力バリデーションの制限に達するケースもあります。
[8] 2010年問題、2020年問題、2021年問題のようにその他の値域制限に起因する場合もあります。
[37] Samsung SGH-C170 等 Agere チップセットを使った携帯電話は、 [ , ] の日付しか扱えず、 以降に正常動作しなくなったとされます。 >>36 これについての情報は少なく、 Wikipedia も要出典としています。 掲示板の当時の書き込みで異常動作が報告されています >>35。
[47] Wayback Machine, https://web.archive.org/web/20080209230400/http://libsnap.dom.edu/ClasPlus/ADDONS/Y2K.TXT
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時など同じ名前の日時が一定期間経過後に繰り返される日時形式では、 当然ながら一周する期間を超えた範囲を扱うと日時を一意に識別できなくなります。
[4] 狭義の桁溢れ以外に、同じ桁数と仮定して文字列として整列させていたとき、 前提が崩れて順序がおかしくなるという問題が生じる場合もあります。
[11] 解釈の曖昧性が発生する賞味期限表示の2020年問題があります。
[53] その他: 昭和64年問題, 平成31年問題, 旧暦2033年問題
[46] 事情がよくわからないものなど: 西暦2080年問題, 西暦2100年問題
[57] Apple、iOS端末の日付を1970年以前に設定すると再起動できなくなる問題を認める | スラド アップル, https://apple.srad.jp/story/16/02/16/0856251/
[58] iOSデバイスをWi-Fi経由で動作不能にする新たな1970年バグ、iOS 9.3.1以降で修正済み | スラド アップル, https://apple.srad.jp/story/16/04/16/2012232/
[25]
西暦2000年問題が深刻な社会問題となっていた頃、
それは古い計算機の資源が乏しかった故のやむを得ない制約だとか、
先見性のない技術者の落ち度だとかいろいろ言われていました。
[26] 西暦2000年問題の対策にはいろいろな手法がありました。 最も正当的とされた方法は年を2桁から4桁に変更するというものでした。 他に2桁のまま閾値を設けて1900年代か2000年代か切り分けたり、 西暦2桁年号のかわりに元号や皇紀2桁年号を使ったりする手法もあり、 特に前者は手軽な対策として相当広範囲で採用されたのですが、 それは場当たり的で解決を先送りしただけの、 悪い対策手法だという非難もありました。
[27] そんな時代に風刺的に話題になったのが西暦10000年問題でした。 西暦2000年問題の対策で年を4桁化したところで、 所詮それも解決を西暦9999年まで先送りしたに過ぎないのです。 そんな先の時代まで今のシステムが動き続けるとは思えないでしょうか。 でもそれこそが、西暦2000年問題を引き起こした怠惰で先見性のない技術者達の判断ではなかったのでしょうか。 問題を本質的に解決するためには、 4桁化ではなく無限の未来まで扱えるような改修をしなければならないのではありますまいか。
[28] 現実的に考えて、 無限の過去から無限の未来まで、 無限の精度で記述できる日時形式と日時処理システムというものは、 実装不能です。
[29] 従って設計者はそのシステムの用途から実用上十分な値域と精度を考えて決める必要があります。 そしてその値域の限界に到達しそうなときにどのような対策を取るか、 少なくても対策を取り得る余地くらいは予め供えておく必要があるでしょう。
[30] そしてその意図を明確に言語化し、 後進の技術者達に伝承したり、 発注者に報告したりしなければなりません。
[31] 少なくてもそれはその当時の技術的制約とアプリケーションの要求から導かれた妥協点であったはずです。 それを受け継いだ人々は、技術的負債などの陳腐な言葉で侮辱することなく、 現に稼働するシステムと真摯に向き合うべきです。
[33]
現実には前後に既にその先十数年程度で不具合を生じるプログラムが公開、販売されていたことが知られています。
[66]
桁溢れの他に、計算量にも配慮が必要です。
カレンダー(日時設定)の機能制限により 2016年1月1日(金)以降日時表示が正しく表示できなくなります。2016年1月1日(金)以降も正しい日時表示でのご利用を希望されるお客さまは、機種変更されることをお勧めいたします。
2016年1月1日(金)以降、発着信履歴およびメール送受信時間等の時刻表示も正しく表示できなくなります。
私のケータイのカレンダーは「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日からカレンダーが始まっていた。
[23] この記事の筆者は「変な質問」と謙遜しているが、 製造・販売している側は答えられて当然の基本中の基本の仕様のはず。 それすらまともに答えられないのだから、 2020年問題や2021年問題を引き起こすのは必然だったということだ。
[32] Exchange Server、新年早々「2201010001」を long に変換できないエラー | スラド デベロッパー, https://developers.srad.jp/story/22/01/03/085228/
Microsoft によると「2201010001」はマルウェアスキャンエンジンで使用するシグニチャファイルのバージョンだという。バージョンの先頭 6 桁は YYMMDD であり、2021年までは問題なかったものの、2022年の日付のバージョンでは long (int32) の最大値 2,147,483,647を超えて問題が発覚したようだ。
[45] 日時処理のための年ではなく、日付を転用した版番号の処理という変化球。
[41] 292277026596年問題 - アンサイクロペディア (, ) https://ja.uncyclopedia.info/wiki/292277026596%E5%B9%B4%E5%95%8F%E9%A1%8C