ほぼ都市伝説みたいな話なんだけどさ。
IT業界は、黎明期から今なお引きずられてる問題が潜んでるんだ。
ちゃんと対応策もあるから。
2025年問題
2038年問題
そんな先のことは考えてられなかったのか。技術の発達で問題解決できるだろうからと先送りしたのか。
なんでこー後から後から出て来るのか。。
先送りするならするで、ちゃんと言っといてよ。。
都市伝説で済むのか
2025年問題のほうが軽い気がする。
2035年問題もなんとかなるか。
とはいえ、認識はしとかないとね。
そして対策を考えねばだ。
2025年問題
昭和100年問題とも。
察しがいい人は、昭和100年って聞いただけで、あぁーってなるかもｗ
特に官公庁とか金融関係かな。
和暦使ってる業界では深刻かもしれない話。
年を2文字で扱ってると、昭和100年は「00年」。
これまでは64年を過ぎても、昭和96年とかで処理できてたところ、00年になったらどおなっちゃうかなって話。
もう昭和なんてないだろって思うでしょ？
けど昭和生まれの人が生きてる間は、昭和で処理してる可能性あんのよ。しかもプログラムは膨大だから、どこに00年問題が潜んでるか、すぐには分からないってことで。
それが2025年なの。
ちなみにそのあたりは対照表で確認しよう。
先んじて対策しておけばなんとかなるでしょ。
確認対象は膨大だけど、終わらない作業はないよ。
みず○銀行さんとかヤバそうｗ
2038年問題
2038年1月19日 3時4分8秒 UTC（12時14分8秒 JST）にコンピューターの時計が壊れる問題。
1970年1月1日 0時0分0秒からカウントアップしてると、上記のタイミングで桁あふれする。
32ビット整数型だと2,147,483,647秒が上限。21億秒って。。
だいたい68年。たしかに先のことだな。。
ちなみに、世の中にはうるう秒って考え方があるから、途中でちょっと変わってるかもね。
64ビットマシンにすれば済む。
かと思いきや、そんな甘い話じゃない。
すでに作成済みのプログラムには、日付のカウントを32ビットの整数型でやっちゃってるものもあろう。すでにコンパイル済みのもののうち、開発環境が終わってるものがあるからね。VB6とか。
あとはOSの中身ね。古いOSだと、時計の扱いが32ビットってこともあるみたいで。
意外と根が深い。
2000年問題は大丈夫だったし
2000年問題ってのがあった。
Y2Kと呼ばれてたやつ。
これは問題点がふたつあったんだ。
ひとつは、2文字管理で「00」になっちゃったら1900年なのか2000年なのか2100なのか分からなくなっちゃう。だから1月1日に第1の波があった。
もうひとつは、2000年をうるう年と認識できるかって話。だから2月29日に第2の波があった。（4で割り切れても、100年ごとに、400で割り切れないと平年なんだよ。2000はうるう年だけど2100年は平年。）
ちなみにどっちもさざ波。
ほとんどのところで何もなかったはずだよ。
もちろん事前の対策やら確認やらをちゃんと済ませてたってのもあって。
そんなんだから、2025年問題も2038年問題も、ちゃんと対策すればいーんだよ。
余裕はないと思うよ
まだ先のこと。
って思うでしょ？
けっこーすぐだから。
特に2025年問題は、もうあと数年。
もしシステム刷新が必要なほどの深刻な話だったら、刷新に1年とかそれ以上かかる計算しといてね。
ただでさえエンジニア不足してるんだから。（← これは団塊世代問題）
他にもVB問題とかCOBOL問題とかIPv4問題とかINS64問題とかIE問題とかWindows 11対応とかあるからさ。
他にもね。
詳しくはまたいずれ。
ご意見やご感想などお聞かせください！ コメント機能です。