ばぐとらぶごる

開発者もすなるぶろぐといふものを、エンバグ野郎もしてみむとてするなり。

伺か Advent Calender 2021/12/22 : YAYAとSSPの西暦30828年問題について

西暦2038年問題

皆さんは西暦2038年問題って聞いたことあります?

2000年問題ってあったよねというインターネット老人会の会員の皆様はともかくとしまして、C/C++標準ライブラリの時刻の32bit内部表現が2038年ごろ限界を迎えてしまうというやつです。

Linux/FreeBSDなど、だいたいが64ビット化された今だと「ふ~ん」で済んでしまう感じですけれど、Windowsのようなまだ32bitアプリが山盛りな環境では多少問題になりえます。なお伺か(SSP)も32bitアプリです。そりゃ大変だ!

対策済です

といってもまあせいぜい日付表示がバグるぐらいで、起動できないなんてことはたぶんないと思うのですが、SSPはだいぶ前からOSのAPIを直接使って処理しており、2038年問題の影響をたぶん受けません。

YAYAについては、先日Tc568-2で改修作業が終わり、

  • 内部の整数表現が64bit符号つきになった
  • 時刻表現はC/C++と同じ仕様のままだが同じく64bitに拡張された
  • 時刻取得処理は直接WindowsAPIに確認しに行くので制約がなくなった

ということで、こちらも問題がなくなっています。

SHIORIを差し替えれば、たぶんもへじ男爵が2038年以降に頓珍漢なことを言う心配もありません!やったね!

里々?知らない子ですね…そのうち思い出したらなんとかします大丈夫でした*1

実際にやってみた。

2021/12/24の1000億秒後はいつでしょうか?

f:id:ponapalt:20211224054830p:plain

5190年11月8日だそうです。へぇ~…

誰が使うんじゃこんなん。

奴は(日付問題)四天王の中でも最弱…

しかし上には上がおりまして、対策済みのこれらの環境でも、Windows上限定ですが、さらに後に問題が確実に発生します。その年とは…

西暦30828年に確実にバグります。

Windowsのファイル更新日付管理などに使われているFILETIMEが、30828年に完全に溢れて詰みます。

しかしご安心ください。西暦30828年には確実にWindowsもMicr○s○ftも滅亡していますから、もはや誰も心配する必要はないのです。よかったね!

今回はここまでです。

adventar.org

初出:2021/12/24に12/22用に後付けしました。

*1:里々も影響はありませんでした