文章保管庫

Y2Kより先の問題(2000. 1. 4)

2000年問題ってのは、もうご存じの方も多いですよね。
これまでコンピュータが下2桁で年を扱ってきた名残が残り続けてしまった恐ろしい例です。
というわけで、ここでは西暦2000年問題以外の、年に関する問題を取り扱ってみましょう。

■まず、西暦2000年問題って?

　よく、Y2Kと略されますが、Y は Year、K は 1000倍を表す接頭語です。
　だからまぁ、Y2K 問題ってなりますね。
　西暦2000年問題というのは、メモリの効果だった時代、メモリ領域を節約するために、年を下2桁で表していた時代の名残です。
　当時のプログラマー達、まぁ、コンピュータに搭載されていたメモリが 128KBでも多すぎなんじゃないかと言われていた時代ですね（注：128MBではないですよ）。
　そのころは、慣例でした。
　プログラマーの養成学校では、当然のように2桁で扱うことが教えられてきましたから、彼らの作るプログラムはほとんどが2桁になってしまったわけですね。
　そして、表示されるときや曜日を扱うときに、それら2桁の数字には自動的に 19の数字が補われる。
　2000年が来れば、下2桁は00何だから（ここら辺はCDのジャケットの裏側を見れば分かりますね）、これに19が補われて1900年だ。
　これが、2000年問題の概略です。
　106歳のおばあさんに小学校から入学通知が来たり、曜日を扱う仕事が狂ってしまったりと、対応が送れると、とんでもないことになります。
　ついでに、2000年は閏年なのに、1900年は閏年じゃないときたもんだ。日付自体もくるっちまう。
　（注：4年に一度の閏年は100年に一度は閏年ではなくなりますが、400年に一度閏年になります…、ややこしい）

　また、分の悪いことに、デバッグをしやすくするために、99といった数字をプログラムの停止とか、裏技みたいなことに割り当てておいたわけですね。
　それもまた、悪かったですね。
　（実際、1999年1月には、医療機器やタクシーで問題が発生しました）

　彼らもまた、そんな古くさい機器が未来永劫まで使われるとは思っていなかったのです。
　なんとまぁ、99年まで使われてしまったわけですな。

　それが、人工衛星から飛ばすデータまで桁足らずになってしまったってわけで、地上にある GPS は大混乱を起こすわけです。
　人によっては、これを某予言者の地獄の大魔王になぞらえています。

　まぁ、当時のプログラマーがみんな未来のことを考えていなかったわけでもなく、中でも電話で有名なNTT。
　ここの対応は、とてつもなく素早かったといいます。
　ずいぶん前からプログラムの改良を続けていたらしく、「次に心配すべきなのは10000年問題だ！」と言っておりますね。

　とまぁ、2000年にあやかって、いろいろと悪事をするヤツも出てくるし、飛行機の飛行管制システムが狂って、飛行機が落ちるんじゃないかとか、某アミューズメントパークの乗り物が落ちるんじゃないかとか、必要な心配と必要でない心配の区別が付かなくなっている人も多いはずです。

　というのも当たり前。
　目の前にある時計やオモチャやビデオから、核兵器に至るまで、2000年になってみなきゃ分からない。
　とにかく、未知すぎる問題を含みすぎているのです。
　でもまぁ、unlha32.dllとか、遊園地の乗り物みたいに、日付とは全く無縁の機能しかないものには、基本的に問題は生じないことになっています。
　例えば、あなたが昔作った、割り箸ゴム鉄砲。あれに、2000年になったら問題が起きるのかと言えば、No! と言うしかないでしょうな。
　問題なのは、それ自体から問題が生じるわけではなくて、それに関連したところ、例えば、unlha32.dllを利用するプログラムとか、乗り物を動かす電力システムのエネルギー供給源である石油がタンカーで送られてくるとか、そういった所に問題があるのです。
　割り箸ゴム鉄砲でも、割り箸を輸入するときに使う船が故障してしまったら？　と考えたら、作れなくなりますね。　問題が発生すると思っちゃうな。
　某サイトの掲示板で「2000年問題とは、2000年になると世界中のコンピュータが一斉に狂いだし、人間を襲い始める」と書いてありましたが、まんざらうそじゃありません。例えば某ロシアの核ミサイル。防衛システムの誤作動により敵から攻撃されたと勘違いして誤発射 → 某国から報復 → 第3次世界大戦などという状態もシュミレートされていたりする次第であります。

　ああ、怖いねぇ。
　それから2000年問題が簡単に解決できるかというと、そういうわけでもない。
　プログラムなんてのは、プログラマをやっていれば分かると思うけど、メモリの使い方には逐一神経をとがらすものです。
　2桁だけ扱っていればメモリは1バイトですんだのに、4桁になったとたんに2バイト必要になったりと…。
　アセンブリ言語でメモリ直接参照をやっていたら、もうアウトですね。
　1から書き直した方が早いくらいだ。

　それから、銀行のシステムなんかに、大昔から使われているCOBOLとかフォートランとかの言語。
　今みたいにCやBASICやJava言語が使われていたわけではないですから、今ではもう、担当したプログラマは引退していることが多いんですね。
　今の技術者に「直せ！」といっても、難しい話なんです。
　1から作り直した方が早い。
　ってことは、プログラムを委託しなくちゃならん。
　今は不景気だぞ。そんな金どこにある?

　これも、2000年問題の一種です。大量の金を政府が準備しているのも、そのためなんです。

　さて、引退したプログラマ。
　今は不況のために、職から退いている人が多いんですね。
　こういった人を雇おうという動きも多くなっています。
　2000年問題で、雇用対策をクリア。
　そういった企業も、多くなっていますね。

　だから、2000年問題、そんなに暗いことばかりじゃないんです。
　ええ。

　おっといけない。ここでは2000問題以外を語るんだったっけ…。

■ハードウェア側の日付管理

　これは、いわゆるBIOSの問題です。
　BIOSはメインメモリにおかれることが多く、メモリ節約にも大きく関わるため、なるべく小さくしようとするのが普通です。
　よって、当然のように2桁で年を扱っています。
　BIOS を変更（というか、この場合はファンクションの追加）すると、当然のようにプログラム、オペレーティングシステムの対応が必要になってきます。
　せっかく追加したファンクションも、誰も使ってくれなければ意味が無いというわけです。

　……。

　おっと、これも2000年問題だったね。

■機種別のお話

　まず、もっとも普及していると思われるPC/AT互換機。
　これは、メーカーによって新仕様と旧仕様が混同している状態といったところでしょうか。
　新仕様により、問題は解決されてはいますが、これに対応していないアプリケーションは未対応ということになります。

　そして、一昔前にはやっていた PC98シリーズ（NXは含みません）。
　下2桁のみの管理です。
　しかし、曜日と年を対応させていませんから、それを解釈するプログラム次第で、上2桁は自由に決められます。
　日付が1つ増えるたびに、曜日も1つ増えるという、単純な構造です。
　（でも、00年の閏年はどうなるんだろう？ 1900は閏年じゃないけど、2000年は閏年だよ）
　MS-DOSでは、80〜99を19xx、00〜79を20xxとして扱っているようで、それに曜日を対応させています。

　Macintoshに2000年問題はないのか?　と聞かれる人がいるようですが、まず、無いといって間違いそうです。
　Macintoshでは、日付管理のための強烈な命令が準備されており、それを使うのが一般的な手段になっているそうで、それを使えば相当先まで年問題は解決されるとのこと。
　また、MS-DOSのようにフリーソフトプログラマが育たなかったこと、あまりプログラマにシステムの細かい部分をいじくる部分が古い時代に誕生しなかったことも功を奏し、「Macintoshは安全」ということになっているのだそうです。

■MS-DOSのファイルシステムの問題

　おれはMS-DOSユーザーじゃない、Windowsユーザーなんだい！　と言っている君、残念でした。
　WindowsはNTだろうと95だろうと、MS-DOSのファイルシステムをほとんどそのまま継承しています。

　だから、他人事じゃないんだよ。

　ま、そんなところ。

　で、ファイルシステムが抱える年の問題。
　それは、年を７ビットで管理しているということ。
　MS-DOSファイルシステムでは、年を1980からの経過年で表しているため、1980 + 127 = 2107 年が最後になります。
　なーんだ、まだまだ先のことじゃん、と思っているあなた。
　そういうことを言ってて 2000年問題は起きたのです。

　これは、深刻な問題なのです。
　では、今すぐにファイルシステムを変えればよいのかというと、そういうわけでもないんです。
　今存在する、恐ろしい数のプログラムは、その新ファイルシステムについていけなくなります。
　つまり、新しいファイルシステムを採用したせいで、使えなくなるプログラムがゴミのように積まれるわけです。

　107年後の人類達。大変だねぇ。

■C言語の抱える問題

　C言語には、標準ライブラリの構造体として time_t があります。
　これは、32ビットで日付と時刻を表しているのですが、ここに問題が発生します。
　（実際には、最初の１ビットは符号として機能しますので実質31ビットといえます）
　time_t は、1970年 1月 1日 0時 0分 0秒（これは、グリニッジ天文台が標準です）からの経過時間で表されているのです。
　これで行くと、2038年1月19日 3:14:08am で限界が来てしまうことになります。
　これは、けっこう間近に迫る問題ですね。
　（たしか、どっかで「2037年問題」って書いてあったのも見かけたような気がするけど、Microsoftでは「2038年」と言っているから、そっちを信用しましょう）

　解決策としては、これから作られるプログラムはすべてオペレーティングシステムに依存するようにするとか、そういったことしかできません。
　ただ、オペレーティングシステム自体にも限界があるから、これも完全な解決策とは言えません。　すでにC言語の time_t を使ったプログラムでは、書き直す以外に解決をすることはできません。

　ところで、この time_t 自体の定義を書き換えるのはどうか、ということですが、これがまた難しいのです。
　time_t は ANSI C の仕様の一つです。
　少し難しい話になりますが、「C言語」というのはあくまで言語であって、コンパイラそのものをさすわけではありません。
　Visual C/C++ とか、Borland C/C++ というのは開発ツールの名前ですが、これと「C言語」のどこが違うのか、というと、「日本人と日本語の差」みたいなものです。
　「C言語」は決まり事の固まりであって、それを「買う」とかいうことは、通常考えられません。
　あくまで買うのは、その仕様に乗っ取ったソフトのほうです。

　さて、ソフトの方に改良を施せば2038年問題は解決するように感じられますが、それでは「仕様に沿っていない言語」ということになってしまい、「C」とは呼べなくなってしまいます。
　また、ANSI C の仕様を勝手に書き換えたとしても、ANSI C に沿った開発ツールはたくさん出ていますし、それを利用したプログラムというのも山のようにあり、「仕様」を書き換えるだけだと2038年問題以上の混乱が生じます。
　というわけで、各開発ツール作成メーカーは「仕様」を勝手に変更するわけにもいかず、また「仕様」を定めている ANSI C も、仕様変更に伴うリスクが大きすぎて仕様変更ができず、全く困ってしまうわけです。
　とりあえず、各開発ツール作成メーカーが独自拡張した勝手な規格を作って、それをプログラマに使わせるしか方法がありません。
　実際、Microsoft の _dos_getdate() や、Borland(INPRISE) の getdate() も、その独自拡張された関数の一種ととらえることもできます。
　これらの関数の間には当然の事ながら互換性はなく、移植を行う際の大きな障害になります。
　よって、「新しい規格」を誰かが誕生させなければならず、各開発ツール作成メーカーも、それに確実に準拠しなければならないということになります。
　（これまで作られた開発ツールは見捨てます）
　あと 30年以上もあれば、できることでしょう。
　（そうやって、直前まで誰も行動を起こさなかったのが2000年問題なんですけどね。でも、こんなに古いプログラムが長い間使われるってことは、そのプログラマは優秀なプログラムを作っていたということになりますね。日付のところ以外は………）

■オペレーティングシステムの日付管理

　例えばMS-DOSやWindowsの場合、年はWORD型、すなわち16bitで管理されています。
　（MS-DOSは int 21h の Function 212Ah、Windowsでは GetSystemTime() API を参照のこと）
　マニュアルによれば、ここには1980〜2099（文献によっては2079）の値が代入できるとなっていますが、ＯＳ側に改良を施せば、プログラム側の変更なしに2100以上の値を入れて悪いわけではありませんし、これをint型とみなせば、負の値を入れることもできます。
　こう考えると、BIOS - OS間のプログラム変更さえできれば、紀元前32768〜紀元後32767年が扱えることが分かります。
　ってことは、ここで起きるのは、西暦32768年問題ってわけですね。

　さて、年数をlong型、すなわち符号付き32ビットで扱った場合、紀元前2147483648〜紀元後2147483647年が扱えることになります。
　つまり、前後21億年オッケーです。
　その前に、人類が生きているか?　太陽の爆発をどう止めるかを先に考えた方がよいかもしれません。

■いつかは起きる、年の桁あふれ問題

　2000年問題に対応したところで、次に10000年に問題が来ることでしょう。
　これは、桁あふれの問題です。
　すでに、プログラム自体が5桁以上の出力に耐えられていれば別ですが、そんな機能は、8000年先まで使われないことを考えると、考慮しないのが普通です。
　しかし、このプログラムがあと8000年間使われ続けたとしたら…?
　このプログラムそのものでなくても、8000年後までプログラムの形式が伝わっていったとしたら、飛んでもない問題が西暦10000年問題として持ち上がることになります。
　例えば、映画「バックトゥーザフューチャー」の中に出てくるタイムマシン、あれには5桁の西暦を入力することができませんでした。
　西暦10000年には飛べないのです。
　では、今から 10000年後のことも考えたらどうかというと、まだ先の問題が起きます。
　太陽の寿命は残り50億年と言われているのです。

　西暦10万年問題が起こります。
　さらに、西暦100万年問題。
　いや、西暦自体が使われなくなるかもしれない。
　それはそれで大問題です。
　あー、未来人サン、大変じゃのぅ……。

　んなこと考えていないで、さっさと 2000年問題を片づけてしまわにゃ。

※このページは、ソフトウェアに付属のヘルプファイルをWeb用に再構築したものです。大部分に自動変換を施しているため、一部は正しく変換しきれずに表示の乱れている箇所があるかもしれませんが、ご容赦下さい。また、本ドキュメントはアーカイブドキュメントであり、内容は「いじくるつくーる」最終公開時点、あるいは、それより古い時点のものとなっております。一部、内容が古くなっている箇所があるかと思いますが、あらかじめご了承下さい。
※このページへは、自由にリンクしていただいてかまいません。
このページに関するご意見の受け付けは終了しています。

/トップ/いじくるつくーる/ダウンロード/WebHelp/ヘルプトップ/