西暦2038年問題
皆さんは西暦2038年問題って聞いたことあります?
昔2000年問題ってあったよねというインターネット老人会の会員の皆様はともかくとしまして、C/C++標準ライブラリの時刻の32bit内部表現が2038年ごろ限界を迎えてしまうというやつです。
Linux/FreeBSDなど、だいたいが64ビット化された今だと「ふ~ん」で済んでしまう感じですけれど、Windowsのようなまだ32bitアプリが山盛りな環境では多少問題になりえます。なお伺か(SSP)も32bitアプリです。そりゃ大変だ!
対策済です
といってもまあせいぜい日付表示がバグるぐらいで、起動できないなんてことはたぶんないと思うのですが、SSPはだいぶ前からOSのAPIを直接使って処理しており、2038年問題の影響をたぶん受けません。
YAYAについては、先日Tc568-2で改修作業が終わり、
ということで、こちらも問題がなくなっています。
SHIORIを差し替えれば、たぶんもへじ男爵が2038年以降に頓珍漢なことを言う心配もありません!やったね!
里々?知らない子ですね…(そのうち思い出したらなんとかします大丈夫でした*1)
実際にやってみた。
2021/12/24の1000億秒後はいつでしょうか?
5190年11月8日だそうです。へぇ~…
誰が使うんじゃこんなん。
奴は(日付問題)四天王の中でも最弱…
しかし上には上がおりまして、対策済みのこれらの環境でも、Windows上限定ですが、さらに後に問題が確実に発生します。その年とは…
西暦30828年に確実にバグります。
Windowsのファイル更新日付管理などに使われているFILETIMEが、30828年に完全に溢れて詰みます。
しかしご安心ください。西暦30828年には確実にWindowsもMicr○s○ftも滅亡していますから、もはや誰も心配する必要はないのです。よかったね!
今回はここまでです。
初出:2021/12/24に12/22用に後付けしました。
*1:里々も影響はありませんでした