T016 「2038年問題とは」（04/12/27 Mon）

2000年問題

数年前には「2000年問題　通称Y2K」ってのがありましたよね？

年度を2ケタで表している処理系で、99年（1999年）の次が00年となってしまい、

本当は2000年なのに、1900年として処理してしまうというものでした。

では2038年問題とは？

これは、C言語（c,c++等）で作られたプログラム、ソフト、そういったもので起こる現象です。

通常、C言語などの処理系で、「日時」というものを扱う際には、

まず、「1970年1月1日0時0分0秒　グリニッジ標準時刻」からの経過秒数を基に

現在の日時を計算します。

例えば、現在（2004年12月27日19時20分　日本）で、その経過秒数を得ると、

1104142810秒となっていました。これは、まぁ計算するとそうなるんでしょう。たぶん。

では、何が問題なのでしょうか？

通常この経過秒数を格納する変数は、signed long（符号付き32bit整数）で、表現されます。

符号付きというのは32bitのうち1bitを正負（±）の区別に使うので、整数は31bitで表すということです。

では、31bitで表すことができる最大値はいくらでしょうか？これは簡単に計算できます。

2の31乗-1です（0を含むので）から、2147483647となります。

さてお気づきでしょうか？先程、現在の経過秒数は1104142810秒だと書きました。

これは、限界値の約半分ということがわかります。で、年度に直すと、2004-1970 = 34。

つまり、34年で、限界の半分を使ってしまっています。

あと約34年（正確にはあと1043340837秒　2038年1月18日頃？）後には

変数のオーバーフロー（限界値以上の整数は扱えない）が起こります。

実験的に、わざと現在の経過秒数に1043340837秒を足してみました。

すると、ウチの環境では、-2147482513→-2147482512→-2147482511

と、マイナスの数値となってしまいました。しかもマイナスなので、数値自体は

小さくなっていきます。カウントダウン。

これが2038年問題です。恐らく、処理に「日時」が関係してくる

サーバや、銀行、等は対応が必要になるでしょう。

対応は？

とりあえず変数を「unsigned long （符号無し整数）」にしたら普通に問題無くいきましたが、

本当は64bitで対応するのが良いんでしょうね。

long型が64bitのコンパイラと、64bitで扱えるOSといったところでしょうか。