[1] [[計算機システム]]などの[[日時の処理]]では、 [[日時構成要素]]の値が取り扱い可能な [WEAK[(当初設計時に想定した)]] [[値域]]を超えることがあり、問題となります。 [EG[ [40] 例えば[[年]]の[[値域]]が [ [N[1900]], [N[1999]] ] のとき、 [[年]]の値を [N[2000]] としたくなると、[[問題][Y2K]]が起こります。 ]EG] [18] 設計時の想定では遠い[[将来の日時]]だったとしても、 思いの外そのシステムが長生きするのはよくあることです。 [19] 逆パターンで[[値域]]の[[下限]]を超えることはそれほど多くありませんが、 想定よりも応用が広がり、[[過去の日時]]の記述の必要が生じるという可能性もなくはありません。 [67] [[固定長]]データ等の一般の[[桁溢れ問題]]の一種ですが、 [[日時]]の場合は[[将来の日時]]の記述で問題が起こることが多く、 一定期間潜伏した後に特定の期日に大きな問題として発症しがちという特性があります。 -*-*- [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] ;; [52] その他関連: [[西暦2010年問題]] [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]] - [36] [CITE@en[Time formatting and storage bugs - Wikipedia]], [TIME[2022-12-28T01:04:23.000Z]], [TIME[2023-01-01T11:57:00.150Z]] ]REFS] [47] [CITE[Wayback Machine]], [TIME[2023-11-25T11:47:07.000Z]] >[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. - [61] [CITE@ja[okkyの銀河制圧奇譚: sched_clock() overflow after 208.5 days in Linux Kernel]], [TIME[2023-11-15T17:02:55.000Z]], [TIME[2024-01-27T05:20:27.362Z]] - [62] [CITE@en[Linux カーネルの sched_clock() が 208.5 日の連続稼働でオーバーフローする現象について - Red Hat Customer Portal]], [TIME[2024-01-27T05:21:16.000Z]] - [60] [CITE[新208.5日問題 - Systems with Intel® Xeon® Processor E5 hung after upgrade of Red Hat Enterprise Linux 6]], [TIME[2014-02-02T03:41:35.000Z]], [TIME[2024-01-27T05:20:02.127Z]] - [59] [CITE@ja[新208.5日問題、LinuxカーネルのバグとXeonのバグの合わせで発生 | スラド Linux]], [TIME[2024-01-27T05:19:46.000Z]] - [63] [CITE@ja-JP[HPE サーバーおよびストレージ製品用 SAS SSD不具合のお知らせ 2019年12月20日 | HPE 日本]], [TIME[2024-02-20T07:43:20.000Z]], [TIME[2024-02-22T04:30:23.337Z]] - [64] [CITE@ja[3万2768時間が経過して発生した石巻市戸籍情報システムの障害についてまとめてみた - piyolog]], [TIME[2024-02-22T04:30:49.000Z]], [TIME[2024-02-22T04:30:50.016Z]] * 循環型日時系の一周 [14] [[干支]]、[[GPS時]]など同じ名前の[[日時]]が一定期間経過後に繰り返される[[日時形式]]では、 当然ながら一周する期間を超えた範囲を扱うと[[日時]]を一意に識別できなくなります。 [EG[ [17] [[昭和]]は64年まであったため、 [[元号]]と[[干支]]だけでは[[年]]を一意に特定できません。 ]EG] [15] [[2000年問題]]や [[100年問題]]もこの一種とも言えます。 * 整列 [4] 狭義の[[桁溢れ]]以外に、同じ[[桁]]数と仮定して[[文字列]]として[[整列][日時の整列]]させていたとき、 前提が崩れて順序がおかしくなるという問題が生じる場合もあります。 * その他 [11] 解釈の曖昧性が発生する[[賞味期限表示]]の[[2020年問題]]があります。 [24] [[グレゴリオ閏日]]に関する[[2100年問題]]があります。 [53] その他: [[昭和64年問題]], [[平成31年問題]], [[旧暦2033年問題]] [46] 事情がよくわからないものなど: [[西暦2080年問題]], [[西暦2100年問題]] [57] [CITE@ja[Apple、iOS端末の日付を1970年以前に設定すると再起動できなくなる問題を認める | スラド アップル]], [TIME[2024-01-22T13:46:42.000Z]] [58] [CITE@ja[iOSデバイスをWi-Fi経由で動作不能にする新たな1970年バグ、iOS 9.3.1以降で修正済み | スラド アップル]], [TIME[2024-01-22T13:48:34.000Z]] - [54] [CITE@en-us[Windows 10 Y3K Bug: Won't Install After January 18, 3001]], [TIME[2020-03-02T21:03:58.000Z]], [TIME[2024-01-22T12:48:41.501Z]] - [55] [CITE@ja[Windows10に3000年(Y3K)問題が見つかる | ニッチなPCゲーマーの環境構築Z]], [TIME[2024-01-22T12:48:56.000Z]] - [56] [CITE@ja[Windows 10で3001年1月19日にフリーズする不具合が確認される | スラド IT]], [TIME[2024-01-22T12:49:38.000Z]] * 日時処理はどう設計するべきなのか [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年問題]] ]] [65] 関連: [[100年問題]] * 関連 [66] [[桁溢れ]]の他に、[[計算量]]にも配慮が必要です。 [SEE[ [[日時計算ソフトウェアのパフォーマンス問題]] ]] [21] [[旧暦2033年問題]]は性質が異なります。 -*-*- [68] 社会問題を「○○年問題」という謎の風習があります。おそらく[[西暦2000年問題]]がブームになったあとに流行り始めたのでしょうが、 未だに続いています。 ○○は[[西暦年]]を入れます。 [69] 主に[[メディア]]や[[したり顔]]の評論家などが煽るときに使われるようです。 たまに専門家や公的機関等が使っているところも見かけます。 [70] 不思議なことにその当の○○年が近づくと意外と使われなくなります。 ○○年において「今年は○○年問題の年ですが、・・・」のように使うのを見たことはあまりありません。 もしかしたら使っている人もいるのかもしれませんが、 ○○問題が深刻であればあるほど大騒ぎになって専門外の人にも自然と耳に入ってくるはずなのに、 そういうことはまずありません。 [71] もし「○○年には××が起こる」という予言が的中すればその○○年や直前、 あるいはそれ以後のは「××が起こっている」「××問題」 のように伝えられるでしょうし、予言が外れたら予言者は何事もなかったかのように新しい予言に切り替えるまでです。 どちらの場合でも「○○年問題」という固有名詞で煽る必要が予言者には無くなりますから、 誰もそれを言わなくなるという構造がありそうです。 [72] なお[[日本語圏]]以外ではこのような風習は一般化していないようです。 [73] どうもこの種の○○年問題の乱発は、一般の人々が「○○年問題」から関心を失う結果をもたらしているように思われます。 発端の[[西暦2000年問題]]からして対策が成功して大きな被害を出さなかったこともあって、 無駄な空騒ぎであるという[[偽史]]が一部で信じられているようですが ([SEE[ [[西暦2000年問題]] ]])、 ○○年問題が○○年には何もなかったかのように消え去ることの連発で、 もはや「○○年問題」という言葉が求心力を失っているとみられます。 本来なら○○年まで一致団結して頑張って対策しようという趣旨なのかもしれませんが、 この言葉にそのような力は無くなっているでしょう。 (それでも馬鹿の一つ覚えのように○○年問題を創出する人々がいるということは、 一定の層には受容されているのでしょう。) * メモ [FIG(quote)[ [FIGCAPTION[ [12] [CITE@ja[SHARP社製一部携帯電話をご利用中のお客さまへ大切なご案内 | スマートフォン・携帯電話 | ソフトバンク]] (掲載日:2015年10月9日 最終掲載日:2016年1月14日 [TIME[2020-01-02 22:13:34 +09:00]]) ]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]] ]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]] > 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]] - [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]] - [44] [CITE@en[Remember the Y2K bug? Microsoft confirms new Y2K22 issue | Science & Tech News | Sky News]], [TIME[2023-11-25T06:52:13.000Z]] [45] [[日時処理]]のための[[年]]ではなく、[[日付]]を転用した[[版番号]]の処理という変化球。 -*-*- [41] [CITE@ja[292277026596年問題 - アンサイクロペディア]] ([TIME[2023-07-11T21:45:44.000Z]], [TIME[2023-08-09T02:07:13.138Z]])