2038年問題とは?

2038年問題

実際のところ、エンジニアであっても、2038年問題を知らない、知っているけど対策したコーディングをしていない、という人が大半ではないでしょうか。

どういう原理で起きるのか?

一言でいうと、オーバーフローが起きるからです。

以下、簡単にまとめてみました。

・プログラミングの日時、時刻表現に、UNIX時間というものがある。

・UNIX時間は、1970年1月1日の00時00分00秒から何秒経過したかで、日時を表現する。

・1970年1月1日00時00分00秒を、「00000000 00000000 00000000 00000000」

・1970年1月1日00時00分01秒を、「00000000 00000000 00000000 00000001」

・1970年1月1日00時00分02秒を、「00000000 00000000 00000000 00000010」

……………

・2038年1月19日03時14分07秒を、「01111111 11111111 11111111 11111111」

・先頭の1バイトは、符号なので、0ならばプラス、1ならばマイナスを表している。

・2038年1月19日03時14分08秒は、「10000000 00000000 00000000 00000000」

・先頭の1バイトは、符号なので、マイナスの時刻を表現していることになり、基準の1970年1月1日00時00分00秒から-2147483648秒されることになる。

・「10000000 00000000 00000000 00000000」は、1901年12月13日20時45分52秒となってしまう。

2000年問題との違い

2000年問題は、年を下二桁だけ使用して扱ったことが原因です。

背景には、今のようにメモリをガンガン使えなかったことがあります。

「1985」の4バイトを使わず、「85」の2バイトを使うようにしたため、1900年と、2000年の区別がつかないという問題です。

つまり、プログラミングする際に、下2桁を使うという処理を入れることが原因で起きますので、アプリケーション側の問題ということになります。

しかし、2038年問題は、アプリケーション側でどう書いていても起きる(厳密には回避策がありますが。)、UNIX時間自体の問題となります。

原因が、2000年問題より、深いレイヤに潜んでいるといえます。

影響を受ける可能性は?

上記の問題は、UNIX時間を使っているシステムで起きます。

C言語だと、新しいコンパイラを使っていれば対策済みですが、C言語を使っているシステムは古いことも多く、メンテナンスがされていなかったり、古いコンパイラを使っていることもあると思うので、その場合は、影響を受ける可能性があります。

また、普段使っているPCもプログラムによって動いていますので、こちらも影響を受ける可能性があります。

32bitのPCを使っている場合に、何かしらの不具合が起きますが、2038年まであと20年あり、最近出ているPCはほとんど64bitなので、よっぽど物持ちがいい人以外は気にする必要はないでしょう。

 ただ…

tech.nikkeibp.co.jp

KDDIの主なシステムは、0.5秒単位で時刻を認識している。そのため、1秒単位で時刻を認識する一般的なシステムの半分の時間しか経過秒数を保持できない。にもかかわらず、このシステムでは、利用可能な最大桁数を増やす設定にしていなかった。

 時間操作をしている場合、2038年を待たずして不具合が発生する事例もあるので、注意しましょう。