西暦２００年問題について

ただし、WinGrooveとＳpkＱＱに関しては、試用期間の計算を行う際にコンピュータのカレンダーを参照しています。　もし、お使いのコンピュータのカレンダー機能、BIOS、もしくはOS (Windows) がアプリケーションに対して正しい日付を提供できない場合には、試用期間が既定日数よりも早く終わってしまう可能性があります。

コンピュータ本体のカレンダー機能やBIOSが2000年問題に対応しているかどうかは、お使いのコンピュータ、あるいはマザーボードのメーカーにお問い合わせ下さい。

今後もし、上記のソフトウェアに2000年問題を引き起こす部分が発見された場合には、本ページにてご案内すると共に、速やかに対策を施したバージョンを配布したいと思います。

コラム : ２０００、２０３８、２０８０？

あざらしがコンピュータのプログラムを書き始めたのは1980年代ですので、既に日付を処理するプログラムを書く場合には、必然的に2000年問題を考慮しなければならない時期に達していました。　ですので、過去にあざらしが制作したすべてのプログラムの日付を処理する部分は、1999年から2000年への繰り上がりを意識して書かれております。

例えば、２桁で表された西暦を４桁に変換しなければならない場合は、だいたい次の様に行ってきました。

00～79　→　2000～2079
80～99　→　1980～1999

ただし、この処理方法も西暦2080年には破綻してしまいます。現在、世の中にはこの様な処理を行っているプログラムが沢山あると思いますが、これらが西暦2080年にもまだ継続して使われているのか、もし使われている場合には、いったいどんな事態になるかは、恐らく私達は見届ける事は出来ないでしょう・・・

また、2080年よりもずっと早い時期に、私達は更なる問題に遭遇します。

日付と時刻を格納するのに多くのプログラムで使われている「32ビット長の time_t 型」は、2038年1月18日19時14分07秒に破綻してしまいます。
1999年に騒がれた2000年問題は
　　「動作しているすべてのプログラムが間違った処理を行っていなければ問題は起こらない」
言い換えれば
　　「2000年に破綻してしまうような書き方をされたプログラムは、どのみち使えるシロモノではない」
と言えるわけですが、time_t に関する2038年問題は
　　「動作しているすべてのプログラムが間違った処理を行っていなくても、time_t 型を使っているすべてのプログラムが日付の計算を正常に行えなくなる」
ので、より深刻です。　恐らくこの年には、現在の西暦2000年問題どころの話ではなくなってしまうような気もします。

今後のプログラム作成で私達が出来る事は、

32ビット長の time_t は絶対に使用しない
日付を表すデータは、可能な限り大きな型で格納する
経過日数や経過時刻の計算は自前で行わず、OSやライブラリを呼び出して行わせる

といったところでしょうか。

＃普段Windowsを使っている私にとっては、20xx年問題うんぬんよりも、普通に使っているだけですぐにシステムダウンしてしまう

「Windowsそのものの不安定さ」

の方がよほど深刻なのですが・・・(このページを書いている時にもFontPageが何度も落ちました)