直前の記事でY2Kという話題があがって、あの頃を思い出しながら記事にしてみます。
Y2KとはYear 2000、2000年問題と呼ばれています。
西暦2000年になるとコンピュータが暴走するといわれていました。
なぜ暴走するのか？
というと、コンピュータの性能が低かったころのデータベースやプログラミングの設計によるもので、2000年を扱うことで不具合が生じるからです。
コンピュータが世に出てきたころ、ファミコンよりも性能が低かったころ、西暦に4桁を使うことが出来ないくらい貧弱なものでした。
西暦に4桁の整数を割り当てるには、0から9999までを扱えるようにするということであり、10進9999を2進数にすると 0010 0011 0000 1111 となり 10 0011 0000 1111 のように最低でも14ビット必要になります。
コンピュータの登場した1970年代ということを踏まえて、西暦の下2桁で、+1900して西暦を表そうという風潮があった。
これは、当時としては画期的とまでは言いませんが、下駄を履かせるという考え方で、貧弱な環境を乗り越えるしか方法はなかったとも言えます。
こういった古いデータベースで管理されたところで、西暦2000年を迎えたり、西暦2000年扱うと、どういうことが起こるのか。
99の次は100なのだが、10進2桁の枠しか用意していないので、99の次は00が来ます。
これは1999年の次は2000年ではなく1900年が来るという認識になります。
例えば、1999年にお金を借りて1年後に返却するという事例があったとします。
お金を借りた1999年の段階で返却日が1900年になって借りられないということが起こるかもしれない。
仮にお金は借りられたけど、2000年になっても返却日と合致しないので、システムが混乱を起こすかもしれない。
我々エンジニアは何をやったかというと、西暦の4桁化ですね。
2000年ごろにはコンピュータの性能や価格も安くなってきたことで、西暦に4桁を割り当てることには、ハード的にもソフト的にもまったく問題がなかった。
ハード的にはハードを制御するソフトウェア、いわゆるファームウェアで西暦を2桁で扱っているものを4桁に対応させる。
つまりファームウェアのバージョンアップです。
ソフト的には、OSや各メーカーのアプリケーションなど、ファームウェア同様に4桁対応させていく。
いわゆるパッチを当てるといった作業です。
まぁ、Y2Kはおそらくはこれといって大問題は起こらずに収束した。
続いて2025年問題。
これは、昭和100年問題で、日本独自の元号で管理されているシステムでY2Kと同様の問題を引き起こす可能性があるということ。
あと丸6年あるが、どうなんでしょうか。
既に昭和も終わり、平成も来年4月30日で終わる。
日本の行政とか金融とか保険とかの書類で昭和を起点にして、データベース上などで現時点で昭和93年のようになっているシステムが対象だろう。
問題が起こるのは日本だけでしょうか。
その次が2038年問題。
こちらの方が世界的に問題になりやすいかもしれません。
1970年1月1日からの経過時間（秒）で日付を管理しているシステムが世界中にはたくさんあります。
これらのシステムが対象となります。
問題が起こるのは2038年1月1日ではなく、2038年1月19日3時14分07秒です。
なにこの中途半端な時刻は？となるだろう。
コンピュータは2進数の世界である。
CPUは4ビット、8ビット、16ビット、32ビット、64ビットと倍々に進化していく。
1970年当時としては計算で容易に扱える値の最大は32ビットだったのでしょう。
32ビットを符号付き整数にすると、16進数でFFFF FFFFは、10進数で-1となる。
符号付き整数は先頭ビットが1だと負を表しています。
つまり、7FFF FFFFの次が8000 0000になるタイミングで、正から負へ変化してしまう。
いわゆるオーバーフローです。
32ビット最大の整数7FFF FFFFを10進数にすると2147483647。
1秒が1なので、
2147483647÷60＝35791394...7
35791394÷60＝596523...14
596523÷24＝24855...3
のように計算すると、24855日3時14分07秒となる。
とりあえず1年365日として割ってみる。
24855÷365＝68...35
68年35日
1970年から2038年まで閏年は毎4年ごとにあって17回。
35－17＝18
よって、
1970年01月01日00時00分00秒から2147483647秒は、68年18日3時14分07秒後は、
2038年01月19日03時14分07秒となる。
という計算です。
ただ、これではまだ不十分なのです。
閏秒があります。
1972年から2017年まで1月1日か7月1日に計27秒増えています。
2038年まであと何秒調整されるのかは、わかりません。
さて、この2038年問題はあと19年後、流石に私も現役エンジニアではありません。
この問題を起こす環境は、Unix環境や、C言語で開発された時刻を取り扱うプログラムなどで、ことが時刻なのでY2Kよりも厄介かと思われています。
どうやって修正していくのでしょうか。
符号付き32ビットを符号なし32ビットにすれば、単純に68年くらい更に先延ばしすることが出来ます。
今現在であれば、64ビットのCPUのパソコンが普通に出回っていますし、私も使っています。
いっそのこと、64ビットで日付を扱うようにしてしまうのでしょうか。
仮に、1年が365.24219日だとすると、×60×60×24して、31556925秒ちょい。
符号付き64ビット整数なら9223372036854775807で、÷31556925で、292277274698年
符号なし64ビット整数なら18446744073709551615で、÷31556925で、584554549396年
宇宙誕生から138億年とか言われてるけど、それを超えるような値ですね。
これくらいなら先延ばししても、その頃にはコンピュータの性能も上がっているだろうからと考えてよいのかな？
でも、4ビットから8ビット、8ビットから16ビット、16ビットから32ビット、32ビットから64ビットと、結構なスピードで進化してきたけど、128ビットCPUとか128ビットOSとかって、まだまだ聞かないですよね。
ゲーム機では128ビットとか言ってたのがあったけど、64ビットCPUを2個搭載しているとかそういう意味だと思う。
でも、既に128ビット無ければ困る環境が出てきています。
それはインターネット環境です。
IPv4とかIPv6とか聞いたことはありますか？
インターネットのアドレスがIPv4の32ビットでは枯渇することが目に見えており、IPv6の128ビット化を進めている最中である。
IPv4とは192.168.0.1のようにドット.で4つに区切られた表記で示され、各区切りには0から255までの値が割り振られ、2564=4294967296。
つまり32ビット環境なわけです。
IPv6は64ビットではなく128ビットです。
なぜ、こんなに一足飛びに増やさなければならないのだろうかというと、IPアドレスの振り方に問題があって、隅から隅まで使い切るような使い方は難しいのです。
まぁ、難しい話しになるのと、タイトルとは別の話しなので、別の記事にしましょうか。
ではでは
↧
2000年問題を振り返り、2025、2038年問題を考える
↧