20xx年問題を考えるブログ

2001年宇宙の旅、200x年、2000年問題、2000年は何かと騒がしい世紀です。 そして、直近の問題は2038年問題。 もう対応に取り掛かっている開発部隊も少なくないと思いますが、未だにこの問題を知らずにノホホンとしているエンジニアもいるとかいないとか・・・ 32ビットパソコンとUNIXタイムの関係性の2038年問題について、ネタ的にブログに書いてみたいと思います。

2038年はUNIXタイムの限界値

1970年からスタートしたUNIXタイム。 1970年1月1日0時0分0秒を0として、1秒毎にカウントアップしていくのが、いわゆるUNIXタイムと言われる積み上げの経過秒数。 ちなみに、いま現時点のUNIXタイムはこちら 刻々と秒を刻み続けて数値が積み上がっていきます。 これが、お金だとしたら嬉しんですが、そうではなく、2038年1月19日3時14分7秒に、終焉を迎えるカウントダウンなのです。 その日に何があるのかというと、積み上げた数値が、2,147,483,647の値を超えるというのが問題なワケです。 この数値が何でマズいのかというと・・・ 2の31乗の数値がこの値です。要するに32ビットの上限値というワケですね。 性格には、32ビットを10進数にすると、4,294,967,295という値になるんだけど、マイナスとプラスが存在するので、2で割った数が今回の値なワケですね。 もちろん、64ビットのパソコン（UNIXサーバー）を使っている場合は、18,446,744,073,709,551,615の半分の9,223,372,036,854,775,807まで大丈夫ということで、今世の中にいる人が生きていない時代まで大丈夫になります。

UNIXタイムってどういう場面で使われているの？

データベースに時刻を書き込む時に、YYYY-MM-DDではなく、UNIXタイムで書き込んでいるシステムを見たことがありますが、UNIX(LINUX)システム自体が、ログで書き込んでいる場合もあります。

対応するには？

簡単に対応したければ、とりあえず、32ビットのサーバー危機を64ビットの危機に交換して、OSを64ビット対応に変更すれば、大丈夫なのですが、これって結構難しい場合もありますよね。 でも、今のところこれしか手がないんですよね。

UNIXタイムの概念を覆せ

そもそも、1970年からのカウントアップって、なんかキリが悪いと思いません？ 今となっては、2000年からでも十分だし、アプリケーションでは、この手の数値は使わずに、年月日、時分秒でロギングするのがいいと思います。

2036年問題？

ZDNET あれ？2036年問題っていうのもある・・・ これは、NTPにおけるインターネットの時刻合わせで使われている時計の値が、2038年問題と同じ様に、値の上限値を迎えるモノらしいです。 こっちは、1900年0時0分0秒を0秒スタートで、 32ビットの10進数値、4294967295秒を迎えるというモノです。 2036年2月6日の00:54:54時点で終焉を迎えるという2038年問題と似て少し非なる問題なので、ヤヤこしや。

2000年問題と昭和100年問題

これはどちらもアプリケーション側の問題で、1990年を90と書き、1995年を95と書いていた悪くしき習慣が招いたトラブルでした。 昭和100年も、2桁で書き続けて、平成令和を無視して、年数をカウントアップしていった先の問題ですが、 どちらも、プログラミングの設計ミスと考えられますね。

100年先はどうなっているかわからん問題

32ビットの数値を64ビットに変更しても、問題を先延ばしにしているだけの事。 ただ、コンピュータというものは、数値の上限値を必ずもっているので、ドラクエのレベル99よりも上がらないという仕様となんら変わらない。 それでも、100年、200年、1000年は大丈夫というシステムを作るのは、プログラマーの腕次第であるとも考えられる。 このブログを見たエンジニアの人、ソフトウェアは、ハードウェアと違って、物理劣化はしないけど、システム劣化はするものであると考えたことありますか？ 自分の作ったシステムは、ノーメンテで、何年ぐらい動くかという思考を設計の時に考えれば、そのちょっとした思考が、こうした問題を回避できる（気がつくことができる）事につながります。 偉そうに言ってますが、これは自分に対して言っているのであって、世の中のプログラマーの人はこういう事は十分に考えていると信じています。 さて、100年遊べるゲームでも作るとしますか。