こだわりの連載技術エッセイ
第5回 コンピュータの時刻 2004年8月24日

以前に「人間の時間,コンピュータの時間」というテーマで連載させていただいたが,今回は「コンピュータの時刻」について書いてみたい.

コンピュータの時刻とはコンピュータが内部に持っている日付時計のことで(TOD:Time of Dayと呼ぶこともある)ハードウェアとして持っている時計そのものを示す場合とソフトウェアで実現されるオペレーティング・システムの機能や組み込み関数としてアプリケーション・プログラムに提供されるものがある.

コンピュータの時刻による問題として有名なものに(もう過ぎてしまったが)「2000年問題」と言われたものがあった.

1.「2000年問題」
2000年問題を簡単におさらいすると「年を2桁の10進数で表して使っているアプリケーション・プログラムは1999年の次の年を1900と解釈してしまう」というもので,この問題の原因はアプリケーション・プログラムにあった.
修正方法はソースコードが残っている場合には日にちのデータを拡大して再コンパイルすれば良いが不幸にしてソースコードが残ってない(または残っていても最新ではない)場合にはその状況に応じた処理が必要でアプリケーション・プログラムを再設計して開発しなければならないような場合も出てくる.
一般に問題無く動いている昔に開発されたソフトウェアをオリジナル開発者以外の人間が変更するには緻密な調査と勇気が必要で該当部分をどのソフトウェアが使っているか完全には分からない場合もある.
目的とした機能改善以外の動作に影響が出ることを「副作用」と呼んでおりソフトウェアの開発には少なからず出くわす問題である.
薬とは違ってこの「副作用」は発症しないと分からないので機能追加を行う際に元のプログラムの修正を避けて新しいプログラムとして並列に置く場合も多い.
こうして古いプログラムは肥大化してますますプログラム構造が分かりにくいものになると言う悪循環に陥る.

2.もう一つの「2000年問題」
上の影響がかなり深刻だった為にあまり言われることは少ないが,もう一つの「2000年問題」とは「2000年はうるう年だった」である.
2000は4で割り切れるので読者諸兄はうるう年であることに疑問を持たれないかも知れないが,うるう年の定義は
4で割り切れて
100で割り切れなくて
400で割り切れて
3200で割り切れない......

というように地球の公転が自転の整数倍では無いので延々と補正が必要になる.
2000年は上の2つの条件ではうるう年にはならないが3番目の「400で割り切れる」という条件でうるう年となる.
このような単純な法則でも意外にうるう年の計算は間違えることが多く2000年というタイミングに限らず筆者の知る限り大手のコンピュータメーカはほとんど経験していると思う.

3.「2038年問題」
最近言われ始めた時刻問題に「2038年問題」がある.
 「2038年問題」とはLinuxを含むUNIX環境やC/C++言語で記述したプログラムで協定世界時(UTC)の2038年1月19日3時14分8秒を過ぎるとシステムが正しく時刻を認識できなくなることをいう.UNIXはシステム内部の時刻を1970年1月1日0時0分0秒(UTC)からの経過秒数で保持していて経過秒数を表す時刻データには32ビットの符号付き整数を使っている.先頭の1ビットは正負の符号を表すために使い最大2の31乗までの秒数(約21億秒)を表現する.これらの処理はハードウェアでは無くオペレーティング・システムの内部で行われる.
経過秒数がその最大数2の31乗秒を超えるのが2038年1月19日3時14分8秒(UTC)となる.経過秒数が2の31乗秒を超えると時刻データの先頭ビットに「1」が立ち,先頭ビットの「1」は負の値であることを意味するので,2の31乗秒を超えた後の内部時刻は1970年の1月1日から約21億秒を引いた1901年12月13日(UTC)に戻ってしまう.

先頭ビット 残りの31ビット  
0 111・・・1111 正の最大数(約21億秒)
+1秒 されると
1 000・・・0000 負の最大数(マイナス約21億秒)
この状況ではシステムの時刻表示がおかしくなるだけでなく,処理に時刻データが必要なプログラムからは時刻が逆行したように見えるために不具合が起きる可能性もある.

4.「2042年問題」
今までの時刻問題がオペレーティング・システムやアプリケーション・プログラムの中に定義された時刻情報の問題であったのに対して「2042年問題」はハードウェアの時刻機能の問題であるのが大きな違いである.
IBM系のメインフレーム・アーキテクチャではハードウェアがTOD(Time of Day)として64ビットのカウンタを持っている.そのカウンタの値がオールゼロの時はグリニチ標準時で1900年1月1日午前0時と決められており,そのカウンタは1マイクロ秒毎に更新される.
1960年代から70年代に開発されていたアーキテクチャの時刻の原点を1900年に設定するのはアーキテクチャに美しさを持たせようとしたIBMらしいと筆者は感じる.
この64ビットのカウンタが2042年9月17日午後11時53分46秒頃に一杯になりオール1になる.(日本時間 18日午前8時53分46秒頃) ソフトウェアのインターフェース上では無くハードウェアの基本のタイマーであるので事態はより深刻かも知れないが,今から拙速に対応するのでは無くあと38年もあるので良く考えるときっと良い解決方法が出てくるものと筆者は信じている.

コンピュータの時刻の問題に共通して言えるのは,設計時の想定を超えてコンピュータとソフトウェアが使われ続けているということで,当時最先端の製品開発をしていた開発者に100年後のことも考えろというのは無理であるし,コンピュータの資源(CPU計算速度,メモリ,記憶装置)が現在よりもはるかに高価だった時代(筆者第2稿参照)にあっては仮に仕様を100年先まで考えたものにしたとしたら過剰な仕様となりむしろ製品としてバランスを欠くものになったと思う.

ソフトウェアは経年変化で壊れることは無いしその土台のコンピュータ・アーキテクチャもまた壊れない.

(光)
<< BACK NEXT >>
Copyright 2003 ASIA NETWORK, Inc. All rights reserved.