2036年問題？

何気なく、2038年問題のことを調べていた。
正確にいえば、「2037年だっけ、2038年だっけ」を調べていたのだが、その途中で「2036年問題」というものを見つけた。

2036年問題とは - IT用語辞典 Weblio辞書

• NTPは1900年1月1日を起点とした秒数で時間を表している
• 範囲は、32桁の2進数
• オーバーフローするのは、2036年2月6日0時54分54秒

あれ？
2038年問題の方を見てみよう。

2038年問題とは - IT用語辞典 Weblio辞書

• UNIX環境では1970年1月1日0時0分0秒を起点とした秒数で時間を表している
• 範囲は、31桁の2進数
• オーバーフローするのは、2038年1月19日

ああ、符号付きかどうかの違いで70年近く差が出てくるのね。

マイナスになることもなさそうなのに、なぜ符号付きにしたのだろう？
当時の事情は知らないのだが、そういうコンピュータが多かったのかもしれん。

C言語だとtime_tで扱うのだけど、今は64bitになっているものが多いと思う。
もしかしたら、64bitのOSしか使っていないせいかも。
ただ、環境依存になることは仕方あるまい。

RTCなんかは割り切ってて、100年計測できるようになってるものが多かったように思うので、日付についてはアプリ管理だ。
昔はLinuxも32bitで扱ってて、どうせRTCチップ用にドライバ作るんだからということで、時計回りは別で扱うようになっていた。
便利なAPIは使えなくなってしまったのだけど、まあ、そういうのもありですな。

time_tの変数をポインタにして、uint32_tなんかでキャストし、またtime_tで直接ポインタから元に戻そうとすると変な値になってしまうから注意したまえ(2回くらいやらかした。。。)。