「2000 年問題」という言葉は, ここ最近メディアでも取り上げられる機会が多くなりました. すでに多くの方が耳にされたことがあるでしょう.
「2000 年問題」とは, 西暦 4 桁のうち下 2 桁しか認識/対応していない ソフトウェアやハードウェアが, 2000 年の下 2 桁 "00" を "1900年" と誤認識してしまう, などの例を代表とする, 西暦 2000 年を迎えた時に主にコンピュータに起こると想定される問題の総称です. Y2K 問題, Year 2000 Bug, Millennium Bug などとも呼ばれます.
古くから使われ続けている基幹システムにおいて, この問題は特に深刻です. もしこれらのシステムが止まれば, 我々の生活を支えている現代社会でのさまざまな活動が 機能停止してしまうといっても過言ではないのです.
では, Linux は 2000 年問題に対応しているのでしょうか? これは, Linux という言葉が指す範囲によります.
Linux "カーネル" は, 時刻の単位として, 1970 年 1 月 1 日 0 時 0 分 0 秒 (Epoch と呼ばれる)からの経過秒数を表す (プラットホームにも依りますが, 少なくとも 32 ビットプロセッサ上では) 32 ビット幅の数値を用いています.
この 32 ビットで表現できる日付は, 2038 年 1 月 19 日 (GMT - グリニッジ標準時間) (注1) までです. これは多くの 32 ビットプラットホーム上の UNIX 系 OS でも同様です. つまり, 少なくとも UNIX 系の OS では, 2000 年よりも 2038 年の方が問題なのです.
2038 年問題に対応するため, 各 UNIX プラットホームの新しいバージョンでは 時刻を 64 ビット幅で取り扱うよう修正する傾向にあります. Linux もいずれは日時を 64 ビット幅で取り扱うようになるでしょう. 64 ビットになれば, 西暦 292,277,266,665 年までは大丈夫です. その頃まで, 人類とコンピュータが今の形で残っているかは, 現時点では全く不明 (注2) です :-)
ともあれ, Linux そのもの, すなわち Linux カーネル自身には西暦 2000 年問題はないといえます.
続いて Linux "ディストリビューション" についてです. Linux ディストリビューションは, 多数のソフトウェアで構成されています. すなわち, ディストリビューションが 2000 年問題に対応しているかどうかは, 含まれているアプリケーションが全て 2000 年問題に対応しているかどうか, 日時を扱うような個々のアプリケーションの対応ができているか, ということに依存します.
アプリケーション側がわざわざ下 2 桁のみで年を取り扱う構造になっていない限り, Linux/UNIX アプリケーションの大多数は, 2000 年問題に対応していると言えるでしょう. 多くの Linux/UNIX アプリケーションでは, 先ほど紹介した 32 ビット幅の数値が日時の格納に使われています.
一般的にも Linux は 2000 年問題に対応済みであると言われています. しかしながら, 数々のデーモン・コマンド・アプリケーションなどの Linux システム全てにおいて問題が存在しないと 保証されているわけではありません.
コンピュータの運用というものは, ソフト, ハード, そしてその利用者をも含んだ総合技術です. ここに含まれる全ての要素, すなわち運用者の心がけといったレベルまでを 分析しないかぎり, 真の 2000 年問題は語れません. したがって, 単なる言葉のトリックを越えて 「2000 年問題対応済」とは簡単には言えないのです.
入力を西暦の下 2 桁のみで行うアプリケーションは, 現時点でも相当数存在しています. このようなもののうち, 出来の悪いアプリケーションでは, 00 と入力すると "2000" ではなく "1900" 年と判断されてしまい, 予想とは違う結果が得られるかもしれません.
閏(うるう)年の問題もあります. 閏年とは, その年数を 4 で割ったときに余りが 0 になる年のことで, この年だけ特別に 2 月が 29 日まであります. しかしその年数が 100 で 割り切れた場合は, 閏年では "なくなります". 更に例外があって, その年数が 400 で割りきれた場合は, 閏年に "なります". 結局 2000 年は閏年になるわけですが, アプリケーション側でこの閏年を扱っている場合, 2000 年 2 月 29 日は存在しないと処理してしまうものも 中にはあるかもしれません.
アプリケーションそれ自体に問題がなくても, リンクしているライブラリに 2000 年問題が潜んでいる可能性があります. 実際 Linux に含まれる C ライブラリの標準関数の一つ strptime() 関数では, アプリケーション側から年数の下 2 桁のみを渡されてしまった場合に, "00" を "1900" と誤ってしまう可能性があります. これは最近の glibc などでは修正されていますが, 古い libc5 を使ったシステムでは問題が発生することがあります
最新のディストリビューションに含まれる多くの アプリケーションは, 既に 2000 年問題に対応し終わっているか, あるいは現在対応下にあります. 古いシステムを使っていない限り, ほとんどのユーザは問題に出会うことはないでしょう.
Linux のソフトウェアの多くは, GPL ライセンスのもとにソースが広く公開されています. 何か問題点を発見した場合には, 実際にソースを辿ることで解決することもできます.
ソースが公開されていないソフトウェア, バイナリ形式でしか提供されないソフトウェアでは, 問題に遭遇したとしても自力では調査することもできず, 問題点が判明したとしても対処することもできず, ただひたすらベンダの対処を待つしかない場合があります.
しかし, Linux システムにおいては, 仮に問題に遭遇したとしても
ケースが多いのです. このように, 公開されていること, 門戸が解放されていること, トラブル時に解決へのパスが開いていることが, (「無料であること」以上に) Linux などのオープン・ソース・ソフトウェアの最大の強みであると言えましょう.
もちろん, ソースの不具合を発見したときには, 是非開発者にフィードバックしましょう.
2000 年問題は, 日付を取り扱うコンピュータ全てに発生しうる問題です. コンピュータとは, OS のカーネルやライブラリ, ユーティリティ, そしてアプリケーションまでを含む総合技術です. Linux 自身や そのディストリビューションに問題がなくても, 全く関係ないところから問題点が噴出するかも知れません. あなたがプログラムやスクリプトを作成したのであれば, それが 2000 年問題に対応しているかどうかは, あなた自身にかかっています.
2000 年はもうすぐやってきます. 引き返すことは出来ません. 無事 2000 年を過ごせるように, 早めのチェックをお勧めします.
2000 年問題の詳細については, 以下のリンク先が参考になるでしょう.
ただし閏秒の存在を考慮すると少なくとも数10秒程度のズレが生じることに注意.