2038年問題

今回は2038年問題について。

このブログは前身がありまして、

そこから記事を移していたのですが、

前身のブログで

前回の記事から一年以上放置した挙句

すっかり2038年問題についての記事を

書くのを忘れてたようで笑

なので、久しぶりに

新しく記事を書きます。

ここからが本題。

2038年問題とは

ざっくりいうと

コンピュータが誤作動を起こす

可能性があるとされている年です。

詳しくいいますと、

2038年1月19日3時14分7秒を過ぎると

コンピュータが誤作動する可能性が

あるとされています。

ぱっと見、

2000年問題や2036年問題と

似ているような気がします。

2036年問題は

（前に書いた記事で

書き忘れましたが）

1900年1月1日からの積算秒数で

時間を表現するシステムにおいて

誤作動が生じてしまう問題です。

2038年問題はどうでしょう。

標準的なC言語が使われているものは

時刻の表現として「UNIX時間」

《1970年1月1日0時0分0秒からの

経過秒数》

を使用しているそうです。

（この経過秒数を表現する型は、UNIXの仕様では、「time_t型」とされているようです）

なぜこの時間からなのか…

最初にそのような機能が実装された際

キリの良い過去の時刻

ということでたまたまこの時間からと

なったようです。

そして、この値（time_t型）は

32ビットの符号付き整数で

実装されていることが多いため、

最大値は (2³¹ - 1) = 2,147,483,647 

となり、

取り扱えるのは

2,147,483,647秒とされている。

経過秒数がこの上限を超えるのは

世界標準時で

2038年1月19日午前3時14分8秒

(日本時間午後12時14分8秒)であり、

その時間を過ぎると

この値がオーバーフローし、

負と扱われるため、

この形式で時刻を管理している

システムはそれまでに対策を

施さなければこの時点以降

正常に動作しなくなると

されています。

ということは、

2000年問題よりも

2036年問題よりも

深刻な状況になるおそれがあります。

〜対策として〜

time_t型を

符号つき64ビット整数型にするという方法があるそうです。

符号つき64ビット整数型の場合、

上限は9,223,372,036,854,775,807

（2⁶³ - 1）

これを秒数に用いると

およそ西暦3000億年まで

使用できるようです。

これですと

事実上問題が発生することは

ないはずです。

そして、

この問題を事前に解決しようと

ジョンタイターが2036年から

IBM5100を求めて

タイムトラベルしてきたという

一連の流れとなるのですね。

さて、

つらつらとかいてきた

ジョンタイター関連のお話は

ここで収束です。

自分で調べられるだけのことを

まとめてきました。

（自己満足というものです。）

もしかしたらちょこちょこっと

過去の記事に訂正をいれることが

あるかもしれません。

さて、次からは

少し前の話題や異世界のお話などを

して行こうと思います。