今から20年以上前、コンピュータの西暦2000年問題というものがあった。
20世紀後半、コンピュータがまだ生まれて間もない頃、メモリが小さい為にそれを節約する目的で、日付け表示をこうプログラミングしていた。
1995年4月20日の場合
年月日
yy-mm-dd
95-04-20
これが2000年になってしまうと、2000年を1900年と認識してしまうため、あちこちで交通機関やライフラインの停止、銀行ATMの異常動作など不具合が起きることが予想された。プログラム修正や手間がかかって大変だったことがあった。
以下のようにyyyyと西暦を示す箇所を修正
yyyy-mm-dd
1995-04-20
多少の混乱や不具合はあったものの、無事2000年を迎える事が出来て今日に至る。ところが2000年問題以上に深刻な2038年問題に関しては、ほとんど知られていないようだ。
・ところで2038年問題とは？
UNIXの32ビットOSの「time_t変数」が上限値（1970年1月1日0時UTCから数えて21億4748万3647秒を超えた値）に達した場合に発生する問題。
2038年1月19日03時14分7秒UTC
(日本時間で同日12時14分7秒。実際には閏秒もあるので、少し早いと思われる)
に桁溢れ起こす問題だ。64ビットOSの場合は全く心配ない。桁溢れまで2,900億年かかる。
少々複雑なので理解されにくく、問題を深刻化しているが、社会全般のコンピュータのうち、大半はUNIX系マシンでありプログラム言語はC言語が使われている。
これらで時刻はtime_tという言葉が使われているが、とある基準時から何秒経過したか❓という処理のされ方をしている。しかも機械なので二進法でカウントされる。
基準時間は
1970年1月1日00時00分00秒UTC
(日本時間で、同日09時00分00秒JST)
これは8ビットの場合
0000 0000
0000 0001 1秒後
二進法の場合0と1で表記する。コンピュータは内部ではこの二進法で全て判断している。一番左側は数字として使えない。
一番左側以外全て"1"になったら桁溢れ
一番左側が"1"になったらアウト❗️
私はドボンと言っている。
①4bitの場合(架空)
2^(4-1)＝8秒、つまりスタートから7秒後に桁あふれし、8秒後に"ドボン"だ。
0000 基準時からスタート
0001 1秒後
0010 2秒後
0011 3秒後
0100 4秒後
0101 5秒後
0110 6秒後
0111 7秒後▶︎桁あふれ
1000 8秒後▶︎ドボン❗️
② 同じく8bitの場合(架空)
2^(8-1)＝128秒
0000 0000 スタート
0000 0001 1秒後
0000 0010 2秒後
〜
0111 1110 126秒後
0111 1111 127秒後▶︎桁あふれ
1000 0000 128秒後にドボン
③ 16bitの場合(架空)
2^(16-1)＝32,768秒後にドボン
④ 32bitの場合 現実の2038年問題
2^(32-1)＝2,147,483,648秒
21億4748万3648秒後、つまり
68年18日3時間14分8秒後にドボン
2038年1月19日03時14分08秒UTC
(日本時間で同日12時14分08秒 JST)
となるはずが、
1901年12月13日20時45分52秒UTC
と表記される。
これが2038年問題だ。
この桁あふれを起こすと、一斉に時間が、1901年12月13日まで100年以上も逆戻りしてしまう。
この問題が前回2000年より深刻なのは
① 2000年問題はアプリ部分の修正で済み、修正パッチで対応できたが、2038年のはOSなど根幹部分の問題があり、修正パッチで済まない。OSそのものを取り替える必要あり。
② 前回は西暦2桁と4桁の違いでわかりやすい問題だったが、2038のは二進法や32ビットなど、専門知識も必要でコンピュータのことを知らない人にはわかりにくい
③ 20年以上前に比べて、日付けデータの入ったコンピュータが激増していること。パソコンだけでなく、周りのスマホ、家電製品やゲーム機など日付けデータ入れてインターネットに接続しているもの、すごく多くないか❓
ただし、OSなら64ビット対応にすれば、日付けは2924億年間はこの問題は起きない。あとはプログラムのみ64ビットにしたり、基準時を1998年1月1日にずらすなど、色々やっているようだ。
Windowsは7以上の64ビット仕様なら、この問題は起きない。Macも同様に起きない。しかし、スマホのiPhoneは対応していないようである。大型コンピュータよりも、家電や細々とした機械に不具合が多発する気がする。そしてWindowsでもXPやVistaといった古いものは、この2038は未対応だ。
現行のiPhoneなら2038年1月1日までしか、日付け変更が出来ないでいる。この問題を回避する為だろう。今現在、世界中全てのiPhone、Androidは2038問題に未対応だ❗️
ただし、現在の最新機種のスマホであっても、17年後も使っているとは考えられず、2030年代半ばには2038年対応済みの機種になると思われるが。
とはいえ、サーバのオープンソースなどには32ビットで動かしているものがかなりあって、今後も使い続けているのは予想でき、64ビットに更新するか先延ばしするようにアップデートしたり、対応が必要である。
・こぼれ話し…2038までの日付基準点
① 1970年1月1日
② 1987年1月5日
③ 2004年1月10日
④ 2021年1月14日
⑤ 2038年1月19日
この中で、①はスタートの基準日。
②の1987年は全体の1/4が経過した日付だ。
③の2004年1月10日は、ちょうど中間地点になる。実は私はこの当時のことを覚えていて、「あと数日で、2038年のあの日までの中間点じゃないか❓」と気がついた。
案の定、あちこちのシステムで不具合が発生した。基準の中間点なので、長期契約のデータなどで計算の不具合が発生したのだ。
さて④の2021年1月14日であるが、これはつい先月だった。だからこのネタをブログに書こうと思った。先月14日はちょうど3/4が経過した日付であり、残りがあと17年いや、16年10ヶ月である。16年って長い？短い？なんかあっという間に来るだろう。その時の私は69歳。月末には70歳になる。
偶然だが、上記の①〜⑤はちょうど17年周期だが、米国東海岸で17年周期で大発生する17年ゼミの発生年と全く一致している。
・私の人生の転換期
上記の①〜⑤、特に②、③、④だが私にとって転換期に当たっている。④は先月。つまり今だということである。全くの偶然だろう。
