[1] 計算機システム などの日時の処理 では、
日時構成要素 の値が取り扱い可能な
(当初設計時に想定した)
値域 を超えることがあり、問題となります。
[40]
例えば年 の値域 が
[ 1900 , 1999 ]
のとき、
年 の値を
2000
としたくなると、問題Y2K が起こります。
[18] 設計時の想定では遠い将来の日時 だったとしても、
思いの外そのシステムが長生きするのはよくあることです。
[19] 逆パターンで値域 の下限 を超えることはそれほど多くありませんが、
想定よりも応用が広がり、過去の日時 の記述の必要が生じるという可能性もなくはありません。
[67] 固定長 データ等の一般の桁溢れ問題 の一種ですが、
日時 の場合は将来の日時 の記述で問題が起こることが多く、
一定期間潜伏した後に特定の期日に大きな問題として発症しがちという特性があります。
[38]
情報交換用日時形式 にせよ、情報処理用日時データ型 にせよ、
実用上は日時 の記述に使うデータサイズに制限を設けざるを得ません。
制限を取り払ってどれだけでも過去の日時 や将来の日時 を表現可能にすると、
RFC 2550の日時形式 のような扱いづらい形式になってしまいます。
[39] CPU やプログラミング言語 の整数型 が64ビットの場合、
それより大きな整数 を扱うには特別な処理が必要となります。
日時 を大きな整数 で扱うと、
近い日時の計算も含めてすべての日時 計算が煩雑で低速になってしまいます。
[22]
2000年問題 への対処も、よくて9999年まで問題を先送りできたに過ぎませんでした。
実際には数十年程度の先送りで延命させたシステムも少なくありませんでした。
桁溢れ問題への本質的な対処は困難です。
呼称 [48]
西暦2000年問題 がこの種の問題では最も有名で、
西暦2000年2000 以外でも代名詞 的に使われることがよくあります。
[51]
昭和100年問題 や民国100年問題 が西暦2000年問題 のようなものと紹介されます。
[50]
Unix time の西暦2038年問題 が
Unix Millennium 2038 Bug
と言われることがあります。
[52] その他関連: 西暦2010年問題 [49]
English ではしばしば rollover と表現されます。
桁溢れ の結果最大値 を超えて 0 や最小値に戻る
(99 から 0 に戻る、 232 - 1 から 0 に戻る、
231 - 1 から -231 に戻る、など)
ことを指していると思われます。
年の桁溢れ [5] 発症パターンとして、
[13] 値域 の上限 を超えて問題が起きる[6] 下2桁で扱っていたので、100年目に問題が起きる[7] n 年から99年を前世紀、0年からn -1年を新世紀として扱っていたので、
二度目のn 年付近で問題が起きる[9] 0年や99年を特別な意味で使っていて問題が起きる[20] 整列 の順序がおかしくなる... というのがあります。
[34]
データ型 レベルの値域 限界に達することもあれば、
日時入力 バリデーション の制限に達するケースもあります。
[10] 年号 の桁溢れ の問題DATE75問題 OS/8の日時 の限界2000年問題 10000年問題 昭和100年問題 民国100年問題 2061年問題 2700年問題 平成100年問題 複数紀元詰め込み の問題整数時刻系の桁溢れ [3] 整数時刻系 および時間 変数の桁溢れ 西暦1989年問題 Deep Impactの日時 2036年問題 2038年問題 49.7日問題 497日問題 24.9日問題 248日問題 512k日問題 [8] 2010年問題 、2020年問題 、2021年問題 のようにその他の値域 制限に起因する場合もあります。
[37]
Samsung SGH-C170
等
Agere チップセットを使った携帯電話 は、
[ 1998-01-01 , 2014-12-31 ]
の日付 しか扱えず、
2015-01-01 以降に正常動作しなくなったとされます。
>>36 Wikipedia も要出典としています。
掲示板 の当時の書き込みで異常動作が報告されています >>35
[35] Samsung C170 - User opinions and reviews - page 2 , 2023-01-01T11:56:49.000Z https://www.gsmarena.com/samsung_c170-reviews-2010p2.php [36] Time formatting and storage bugs - Wikipedia , 2022-12-28T01:04:23.000Z , 2023-01-01T11:57:00.150Z https://en.wikipedia.org/wiki/Time_formatting_and_storage_bugs#Year_2015 [47] Wayback Machine , 2023-11-25T11:47:07.000Z https://web.archive.org/web/20080209230400/http://libsnap.dom.edu/ClasPlus/ADDONS/Y2K.TXT
[61]
okkyの銀河制圧奇譚: sched_clock() overflow after 208.5 days in Linux Kernel , 2023-11-15T17:02:55.000Z , 2024-01-27T05:20:27.362Z http://kenichiokuyama.blogspot.com/2011/12/schedclock-overflow-after-2085-days-in.html?m=1 [62]
Linux カーネルの sched_clock() が 208.5 日の連続稼働でオーバーフローする現象について - Red Hat Customer Portal , 2024-01-27T05:21:16.000Z https://access.redhat.com/ja/solutions/121233 [60]
新208.5日問題 - Systems with Intel® Xeon® Processor E5 hung after upgrade of Red Hat Enterprise Linux 6 , 2014-02-02T03:41:35.000Z , 2024-01-27T05:20:02.127Z http://hisayosh.github.io/posts/2013/12/208days-problem/ [59]
新208.5日問題、LinuxカーネルのバグとXeonのバグの合わせで発生 | スラド Linux , 2024-01-27T05:19:46.000Z https://linux.srad.jp/story/13/12/25/1018223/ [63]
HPE サーバーおよびストレージ製品用 SAS SSD不具合のお知らせ 2019年12月20日 | HPE 日本 , 2024-02-20T07:43:20.000Z , 2024-02-22T04:30:23.337Z https://www.hpe.com/jp/ja/important-notices/fy20-01.html [64]
3万2768時間が経過して発生した石巻市戸籍情報システムの障害についてまとめてみた - piyolog , 2024-02-22T04:30:49.000Z , 2024-02-22T04:30:50.016Z https://piyolog.hatenadiary.jp/entry/2024/02/21/052058 循環型日時系の一周 [14] 干支 、GPS時 など同じ名前の日時 が一定期間経過後に繰り返される日時形式 では、
当然ながら一周する期間を超えた範囲を扱うと日時 を一意に識別できなくなります。
[17] 昭和 は64年まであったため、
元号 と干支 だけでは年 を一意に特定できません。
[15] 2000年問題 や
100年問題 もこの一種とも言えます。
整列 [4] 狭義の桁溢れ 以外に、同じ桁 数と仮定して文字列 として整列日時の整列 させていたとき、
前提が崩れて順序がおかしくなるという問題が生じる場合もあります。
その他 [11]
解釈の曖昧性が発生する賞味期限表示 の2020年問題 があります。
[24]
グレゴリオ閏日 に関する2100年問題 があります。
[53]
その他:
昭和64年問題 ,
平成31年問題 ,
旧暦2033年問題
[46]
事情がよくわからないものなど:
西暦2080年問題 ,
西暦2100年問題
[57] Apple、iOS端末の日付を1970年以前に設定すると再起動できなくなる問題を認める | スラド アップル , 2024-01-22T13:46:42.000Z https://apple.srad.jp/story/16/02/16/0856251/
[58]
iOSデバイスをWi-Fi経由で動作不能にする新たな1970年バグ、iOS 9.3.1以降で修正済み | スラド アップル , 2024-01-22T13:48:34.000Z https://apple.srad.jp/story/16/04/16/2012232/
[54]
Windows 10 Y3K Bug: Won't Install After January 18, 3001 , 2020-03-02T21:03:58.000Z , 2024-01-22T12:48:41.501Z https://www.bleepingcomputer.com/news/microsoft/windows-10-y3k-bug-wont-install-after-january-18-3001/ [55]
Windows10に3000年(Y3K)問題が見つかる | ニッチなPCゲーマーの環境構築Z , 2024-01-22T12:48:56.000Z https://www.nichepcgamer.com/archives/windows10-y3k-problem.html [56] Windows 10で3001年1月19日にフリーズする不具合が確認される | スラド IT , 2024-01-22T12:49:38.000Z https://it.srad.jp/story/20/03/06/141210/ 日時処理はどう設計するべきなのか [25]
西暦2000年問題 が深刻な社会問題となっていた頃、
それは古い計算機 の資源が乏しかった故のやむを得ない制約だとか、
先見性のない技術者の落ち度だとかいろいろ言われていました。
西暦2000年問題
[26]
西暦2000年問題 の対策にはいろいろな手法がありました。
最も正当的とされた方法は年 を2桁から4桁に変更するというものでした。
他に2桁のまま閾値を設けて1900年代か2000年代か切り分けたり、
西暦2桁年号 のかわりに元号 や皇紀2桁年号 を使ったりする手法もあり、
特に前者は手軽な対策として相当広範囲で採用されたのですが、
それは場当たり的で解決を先送りしただけの、
悪い対策手法だという非難もありました。
[27]
そんな時代に風刺的に話題になったのが西暦10000年問題 でした。
西暦2000年問題 の対策で年 を4桁化したところで、
所詮それも解決を西暦9999年まで先送りしたに過ぎないのです。
そんな先の時代まで今のシステムが動き続けるとは思えないでしょうか。
でもそれこそが、西暦2000年問題 を引き起こした怠惰で先見性のない技術者達の判断ではなかったのでしょうか。
問題を本質的に解決するためには、
4桁化ではなく無限の未来未来の日時 まで扱えるような改修をしなければならないのではありますまいか。
[28]
現実的に考えて、
無限の過去過去の日時 から無限の未来将来の日時 まで、
無限の精度秒の小数部 で記述できる日時形式 と日時処理 システムというものは、
実装 不能です。
[29]
従って設計者はそのシステムの用途から実用上十分な値域 と精度 を考えて決める必要があります。
そしてその値域 の限界に到達しそうなときにどのような対策を取るか、
少なくても対策を取り得る余地くらいは予め供えておく必要があるでしょう。
[30]
そしてその意図を明確に言語化し、
後進の技術者達に伝承したり、
発注者に報告したりしなければなりません。
[31]
少なくてもそれはその当時の技術的制約とアプリケーションの要求から導かれた妥協点であったはずです。
それを受け継いだ人々は、技術的負債 などの陳腐な言葉で侮辱することなく、
現に稼働するシステムと真摯に向き合うべきです。
[33]
現実には西暦2000年2000 前後に既にその先十数年程度で不具合を生じるプログラムが公開、販売されていたことが知られています。
西暦2000年問題
[65]
関連: 100年問題
関連 [66]
桁溢れ の他に、計算量 にも配慮が必要です。
日時計算ソフトウェアのパフォーマンス問題
[21] 旧暦2033年問題 は性質が異なります。
[68]
社会問題を「○○年問題」という謎の風習があります。おそらく西暦2000年問題 がブームになったあとに流行り始めたのでしょうが、
未だに続いています。
○○は西暦年 を入れます。
[69]
主にメディア やしたり顔 の評論家などが煽るときに使われるようです。
たまに専門家や公的機関等が使っているところも見かけます。
[70]
不思議なことにその当の○○年が近づくと意外と使われなくなります。
○○年において「今年は○○年問題の年ですが、・・・」のように使うのを見たことはあまりありません。
もしかしたら使っている人もいるのかもしれませんが、
○○問題が深刻であればあるほど大騒ぎになって専門外の人にも自然と耳に入ってくるはずなのに、
そういうことはまずありません。
[71]
もし「○○年には××が起こる」という予言が的中すればその○○年や直前、
あるいはそれ以後のは「××が起こっている」「××問題」
のように伝えられるでしょうし、予言が外れたら予言者は何事もなかったかのように新しい予言に切り替えるまでです。
どちらの場合でも「○○年問題」という固有名詞で煽る必要が予言者には無くなりますから、
誰もそれを言わなくなるという構造がありそうです。
[72]
なお日本語圏 以外ではこのような風習は一般化していないようです。
[73]
どうもこの種の○○年問題の乱発は、一般の人々が「○○年問題」から関心を失う結果をもたらしているように思われます。
発端の西暦2000年問題 からして対策が成功して大きな被害を出さなかったこともあって、
無駄な空騒ぎであるという偽史 が一部で信じられているようですが ( 西暦2000年問題 )、
○○年問題が○○年には何もなかったかのように消え去ることの連発で、
もはや「○○年問題」という言葉が求心力を失っているとみられます。
本来なら○○年まで一致団結して頑張って対策しようという趣旨なのかもしれませんが、
この言葉にそのような力は無くなっているでしょう。
(それでも馬鹿の一つ覚えのように○○年問題を創出する人々がいるということは、
一定の層には受容されているのでしょう。)
メモ [12] SHARP社製一部携帯電話をご利用中のお客さまへ大切なご案内 | スマートフォン・携帯電話 | ソフトバンク
(掲載日:2015年10月9日 最終掲載日:2016年1月14日 2020-01-02 22:13:34 +09:00 )
https://www.softbank.jp/mobile/info/personal/news/product/20151009a/ カレンダー(日時設定)の機能制限により 2016年1月1日(金)以降日時表示が正しく表示できなくなります。2016年1月1日(金)以降も正しい日時表示でのご利用を希望されるお客さまは、機種変更されることをお勧めいたします。
2016年1月1日(金)以降、発着信履歴およびメール送受信時間等の時刻表示も正しく表示できなくなります。
[16] ケータイ電話のカレンダーの果てはどこまで? - エキサイトニュース ,
2009年8月20日 10:00,
2020-11-28T05:12:19.000Z
https://www.excite.co.jp/news/article/E1250562393684/ 私のケータイのカレンダーは「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 に変換できないエラー | スラド デベロッパー , 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] Time formatting and storage bugs - Wikipedia , 2023-11-24T03:13:21.000Z , 2023-11-25T06:51:13.925Z https://en.wikipedia.org/wiki/Time_formatting_and_storage_bugs#Year_2022 [43] 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 , 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] Remember the Y2K bug? Microsoft confirms new Y2K22 issue | Science & Tech News | Sky News , 2023-11-25T06:52:13.000Z https://news.sky.com/story/remember-the-y2k-bug-microsoft-confirms-new-y2k22-issue-12507401 [45] 日時処理 のための年 ではなく、日付 を転用した版番号 の処理という変化球。
[41] 292277026596年問題 - アンサイクロペディア
(2023-07-11T21:45:44.000Z , 2023-08-09T02:07:13.138Z )
https://ja.uncyclopedia.info/wiki/292277026596%E5%B9%B4%E5%95%8F%E9%A1%8C