| Tweet |
(回答先: 映画 「ディアラ」 ４０ 【youtube】 投稿者 愚民党 日時 2008 年 7 月 07 日 21:47:22)
http://journal.mycom.co.jp/series/ityougo/007/index.html
【コラム】
最新IT用語解説
7 10億秒問題(2001年9月9日問題)
2001/09/20
佐藤晃洋
今週のこのコーナーは今までとはちょっと方向性を変えて、「10億秒問題(2001年9月9日問題)」について説明してみたい。この問題、一般ではほとんど話題にもなっていないため、こういう問題があるということは、企業の情報システム担当者にも意外と知られていない。しかし、実は世間の知らないところで、あの「2000年問題」にも匹敵する重要な問題が起きていたかもしれないのだ。
■「10億秒問題」とは?
この「10億秒問題」、名前から「何か時間の問題なんだろう」ということはこれをお読みの方も予想がつくところだろう。ここでいう「10億秒」とは何の時間を指しているのだろうか。その理屈を理解するためには、まずUNIXやWindowsにおけるタイムスタンプの管理システムについて説明しなければならない。
一般的なOSではファイルの更新日時などに使用するクロックを秒単位で管理しているのだが、UNIXやWindowsの場合はそれを、1970年1月1日午前0時(UTC)を起算点とする通算の秒数で管理している(ちなみにこの起算点のことを、専門用語で『epoch(エポック)』という)。今回問題になっている「10億秒」とは、このepochから数えた通算秒数のことを指しているのだが、この「10億秒」を通常の日時に直すと「2001年9月9日午前1時46分40秒(UTC)」(日本時間は＋9時間)となる。
これだけなら何も問題にはならないのだが、一般のアプリケーションの中にはプログラマのミスや手抜きのため、この通算秒数の処理に当たって「秒数は9桁以下」と決めうちして処理を行ってしまうものがある。その場合、アプリケーションが動くPCが10億秒目を迎えると、アプリケーションは日時が「0になった」＝「上記のepochの日時(1970年1月1日)に戻った」と誤認識してしまい、プログラムが誤動作を起こしてしまうのだ。
このあたりはあたかも、「2000年問題」に引っかかった(＝年号を下2桁のみで処理する)コンピュータが「2000年」を「1900年」と誤認識する状況に酷似している。実際海外のニュースサイトには、かつて「2000年問題」が「Year 2000」→「Y2K」と略されて呼ばれたことになぞらえて、この問題を「Second 1,000,000,000」→「S1G」として報道するところもある。
■少なくない問題発生ソフト
この問題、今年に入ってから一部のIT関係者の間では結構話題になっていた。特にCOBOLの世界では数字の処理の際に桁数を固定することが多いらしく(筆者はCOBOLは素人なのでこのあたりは人に聞いた話)、多くの企業でシステムの改修が必要になったようだ。とはいえ前回の2000年問題の時に、世間が大騒ぎになった割には大きなトラブルはほとんど見られなかったせいもあってか、あまり一般の新聞・雑誌などでこの話題が取り上げられることはなかった。
だが、この問題に引っかかったソフトの数は決して少なくない。代表的なところではWindows Meにおいて「システムの復元」機能がこの「10億秒問題」に引っかかり問題が発生することが確認されているし、他にもSolaris用のSun Directory Service、OracleのPro*COBOL(Windows版)なども影響を受けるとの報告がある。
特にFreeBSDは、今回この問題の影響を最も受けたソフトかもしれない。というのも、BSD系OSなどで開発時のバージョン管理に使われているCVSupと呼ばれるツールがまともにこの問題の影響を受けてしまったからだ。しかもその問題が発覚したのはまさに9月9日を過ぎてからで、結果として同OSの最新版となる4.4-RELEASEの公開が遅れていた一因ともなっていた(もちろん公開の遅れはこれ以外にも原因があるのだが)。しかしながら、9月19日付けでバグは解消され、20日には4.4-RELEASEが公開されている。
とりあえず、これらの問題が起こることが確認されているソフトを使用しているユーザーは、できるだけ速やかに当該ソフトを対策済みのバージョンに入れ替えることが必要だ。ホームページでこの問題に関する解説や対応状況の公開を行っているソフトウェアベンダーも多いので、まずは一度ホームページを覗いてみるのもよいだろう。
■次は2038年?
さて、この「10億秒問題」をなんとかクリアした今、開発者の間では次の問題発生日時に関する話題も取り上げられている。中でも多くの開発者が一致して問題と指摘するのが「2038年問題」だ。
これは、今回問題となったUNIXやWindowsのタイムスタンプがプログラム内部で32ビットの符号付き整数(つまり絶対値の部分は31ビット)で管理されており、表現可能な最大秒数がプラスマイナス約21億5千万秒となるからだ。これを先程のepochからの通算秒数として計算すると、2038年1月19日午前3時14分7秒(UTC)に限界を迎えることになるため、特に対策のとられていないプログラムがこの時間を迎えると、やはりプログラムは誤動作を起こすことになる。
これに対しては、多くのLinuxのディストリビューションで内部のタイムカウンタを64ビットに拡張するなど、既に一部対策はとられつつある。しかしこの「タイムスタンプを32ビットで表現する」というのはANSI(米国規格協会)標準で定められたC言語のデータ型(time_t)に起因するものだけに、最終的にはANSI標準が改訂されないことには本質的な対策は難しいだろう。
もちろん、いくらANSI標準が改訂されても、肝心のプログラマ側が手を抜いて「タイムスタンプを32bit決めうちで処理する」ようにプログラムを書いていたのでは2000年問題や今回の10億秒問題の二の舞でしかない。これをお読みの方のなかには現在プログラマの方や、これからプログラマを目指す方も多いと思うが、実際に問題が発生するまでにまだ30年以上時間があるからといって手を抜くことなく、末永く使うことができるようなプログラムを作ることを心がけて欲しい。
http://journal.mycom.co.jp/series/ityougo/007/index.html
▲このページのＴＯＰへ HOME > Ψ空耳の丘Ψ53掲示板
フォローアップ:
投稿コメント全ログ コメント即時配信 スレ建て依頼 削除コメント確認方法
題名には必ず「阿修羅さんへ」と記述してください。
掲示板,ＭＬを含むこのサイトすべての
一切の引用、転載、リンクを許可いたします。確認メールは不要です。
引用元リンクを表示してください。