日時桁溢れ問題

日時桁溢れ問題

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

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

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


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

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

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

年の桁溢れ

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

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

[10] 年号桁溢れの問題

元号コードの桁溢れ

[2] 元号コード

整数時刻系の桁溢れ

[3] 整数時刻系および時間変数の桁溢れ

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

循環型日時系

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

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

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

整列

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

その他

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

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

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

[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年問題

関連

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

メモ

[12] SHARP社製一部携帯電話をご利用中のお客さまへ大切なご案内 | スマートフォン・携帯電話 | ソフトバンク (掲載日:2015年10月9日 最終掲載日:2016年1月14日 ) 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, 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 に変換できないエラー | スラド デベロッパー, https://developers.srad.jp/story/22/01/03/085228/

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