（
1998年4月8日 水曜日 − 2000年問題
2000年問題についての分かりやすい解説は近づく2000年!!備えは万全ですか？やケーススタディ ２０００年問題を考える、西暦２０００年問題に詳しい。問題の原因は旧来のプログラムが西暦の年号を2桁の数値として扱ってきた (例えば1998は98) ため、2000は00になり、頭が19で始まる年号のみを扱うようになっているプログラムでは1900として処理されることにある。その結果、日付を使って計算する年齢や利子、有効期限などの計算に様々な間違いが発生する。中には00を年号の値として受け付けないプログラムもあって、2000になったらどんなエラーが出るか予想できないものもある。 その元凶となっている旧来の日付データの型や記述方法については、Borland社のプログラム言語製品の2000年問題への対応が参考になる。
この問題を知らない人も少なくないという統計データもあり、知っていても何とかなると思っている人も少なくないという。一方、この問題を解決するために大群のプログラマーを雇い、問題のプログラムの修正に躍起となっている会社や政府機関があることも事実。この際だからと、ハードもソフトも入れ替えることを検討している所もたくさんある。
対応策の説明を読むと、大きなデータベースを扱うシステムでは、主にプログラムの修正とリバースエンジニアリングの２つの方法が採用されている。
これはソースコードがなければできない。問題は古いプログラムの中にはソースコードが失われてしまったものもあるほか、ソースコードに手を入れると、新たなエラーが紛れ込む心配が出てくることにある。
競争相手のSRA社の指摘では
｢2000年対応では、修正がある程度パターン化されているためにツールによる自動修正が威力を発揮すると思われがちです。しかし、自動修正ツールは少しでも怪しい箇所まで修正してしまう。完全な修正をすることは出来ないなどの問題を抱えているため、ツールによる修正後、自動修正箇所一つ一つの正当性や修正洩れの確認を人間が行なわなければならず、結果的に余計な工数を要することになります。｣ という問題がある。
これはソースコードがなくても可能。でもこれは新しくプログラムを書くのと大差ないから、元のプログラムと全く同じ機能を提供してくれるという保証はない。
既に店頭で売られている2000年問題対応のハードやソフトに切り替えれば手っ取り早く解決できるかというと、必ずしもそうではない。新しくすると古いシステムで保存されているデータが使えなくなったり、新しいハードやソフトで使えるように変換するのに膨大な時間と費用がかかったりすることもまれではない。
これは既にAccommodate2000という商標で開発され、第一段階のテストも完了している。
その原理については、開発者から直接説明してもらって、一応分かった気でいるけど、下手な要約で誤解を招いても困るから、興味のある人は上記のWebサイトに問合せるべし。