過去のログファイルが大量に出てきたので、見てみたら、こんなのがあった。

/home/temp>touch -t 203801191212 test.txt
/home/temp>touch -t 203801191213 test.txt
/home/temp>touch -t 203801191214 test.txt
/home/temp>touch -t 203801191215 test.txt
touch: 時間指定が正しくありません。
/home/temp>

約２０年くらい前、unix系のOSを使っていて、touchコマンドで日付を変更したら

どのくらいの未来の日付に対応しているのか、興味本位でやって、これが限界なんだな、と思ったやつ。

後に、これが２０３８年問題ってやつだと知った。

今年は昭和１００年で、システム日付の管理で昭和１００年問題を心配していたが、

表面上はなんにも出てこなかった。

過去には２０００年問題もあったが、けっこう対策したおかげで、世間が混乱するような話は聞かずに済んだと思う。

しかし、２０３８年問題はソフトフェアよりもCPUが３２ビットだかららしい。

つまり、CPUが３２ビットだと、2038年１月１９日１２時１５分になるとエラーになるということ。

とは言っても、気づいて対応している部分もあるし、

今ではCPUが６４ビットだし、

OSも32bitを切り捨て出しているし、それほど大きな問題にならないとは思うが、

試しに自分のPCで試してみる。

この通り。

ここで気になったのは古いラズパイだ。

うちのファイルサーバに使っている。

あれ？

そうか、標準時と９時間ズレるんだった。

というか、やっぱり３２ビット環境だとダメか。

じゃあ６４ビット環境だとどのくらいまで未来日付の指定ができるのか？

試したのはいつものlubuntu24.04lts

なんと９９９９年を指定してもエラーにならないけれど２４４６年５月１１日で止まっちゃうのね。

このtouchコマンドの-tオプションで指定できる日付がYYYYなので

西暦１００００年は指定できないことから、ある意味１万年問題なのかもしれないが、

その前に２４４６年問題が発生するようだ。

なんとか暦やなんとかの大予言的な終焉説が出てきそう。

このままやり過ごしたら、未来の人たちから恨まれそうだが、

その頃にはAIがなんとかしてくれるだろう。（楽観視）

ちなみに、この３２ビットで２０３８年のやつは

開始が１９７０年１月１日で、ここからのトータル秒のMAX値なんだそうだ。

これで思いついたのが、ドラえもんの連載開始が１９７０年で、

第１話が元旦なんだよね。

つまり、このタイミングで現れたのは未来の世界でもこの日付が基準になっていて

これより過去の長期滞在はコンピューターの時刻表示に不具合が発生すると懸念していたのかもしれない、という妄想をしてしまう。

２０３８年問題に気付いたときの話