1999.9.13
１９９９年９月９日問題クリア？
それなりに深刻だった９９９９問題も、大事にならずにすんだようだ。
２０００年問題の予行演習みたいな形式でチェックしたところもあるようだ。
というのが、マスコミの記事だ。
年月日入力時に９９９９を入力するとページ終了というプログラムもあるというのが、９９９９問題だ。
つまり、１９９９年９月９日のデータ入力が出来ない。また、内部処理で扱おうとすると処理が中止になるという。
ただ、考えてみて欲しい。
マスコミはいろいろ騒いでいるが、年月日で９９９９を入力することがあるだろうか？
もし、ＹＹＭＤで入力するプログラムがあった場合、１９９８年１０月１０日はどう入力する？
９８１０１０と入力するのではないか？
ということは、９９９９という４桁の数字を入力することはないのではないか？
１９９９年９月９日は、９９０９０９と入力するのではないか？
もし「年」入力欄だとしたら、９９９９年の時に問題になるだろう。
で、「年」入力欄が２桁で、９９という数字がキーになっていた場合、今年の最初（去年の終わり）には、既に問題が発覚しているはずである。
同様に、４桁入力の場合、００００は存在しない。
問題は、「００」という２桁の西暦入力の場合である。
最近になってマスコミが騒いだ、９９９９問題は、全く問題がないか、もしくは既に問題が発生して修正済みということだ。
２０００年問題は１９９９から２０００になる場合の、西暦２桁時の処理であるが、普通に考えると、残りの２０００年問題はうるう年をちゃんと計算しているかどうかだけである。
もちろん、ハードウェア的に、つまりＢＩＯＳ（リアルタイムクロックのＩＣ）が２０００年以降に対応しているかどうかも重要ではあるが、この点については後述する。
本当の問題は、これからである。
２０？？年問題はまだ先だがもっと深刻だと思っている。
unixや MS-DOS等では、いろいろあったが、Ｃ言語の場合、１９００年からや１９７０年からや１９８０年の１月１日０時０分０秒からの秒数だったと記憶している。（もちろん、ライブラリ関数なので、処理系依存で、すべてがそうだとは言えない。）
unixや MS-DOSでプログラムしていたころは、ＯＳから取得したこの秒数を使用して、現在の日付や時刻を取得していた。この秒数を表す数値が、だいたい long（主に３２ビット）であった（ビット数も処理系依存）。doubleのものもあったかもしれないが、だいたい longであったと思う。
符号付整数値は、２の補数だとし、longは３２ビットだとすると、
・longでは、-2147483648〜2147483647
・unsigned longでは、0〜4294967295
となる。ここで、１９００年を基準として longを使用していた場合は全くだめなので、２通りの計算を考えてみる。
＜１９００年を基準として、unsigned longを使用していた場合＞
・１年３６５日（うるう年の場合は３６６日）
・１日（２４＊６０＊６０＝）８６４００秒
とすると、
4294967295／86400=49710.269618055555555555555555556で、49710日と６時間28分15秒になる。
うるう年は、
・西暦で４で割れる数値
・ただし、１００で割れる場合は違う
・ただし、４００で割れる場合はうるう年
となっているので、１９００年はうるう年ではない。
残りは、２０００年を含めて４年ごと。
１９００年からはじめると、１３６年２月５日なので、２０３６年２月５日６時２８分１５秒に最後となり、２０３６年２月５日６時２８分１６秒は、１９００年１月１日０時０分０秒に戻ってしまう計算になる。
＜１９７０年を基準として、longを使用していた場合（ansi time()関数）＞
同様に、
2147483647／86400＝24855.134803240740740740740740741で、24855日と3時間14分7秒になる。
１９７０年からはじめると、６８年１月１８日なので、２０３８年１月１８日３時１４分７秒に最後となり、２０３８年１月１８日３時１４分８秒は、１９８０年１月１日０時０分０秒に戻ってしまう計算になる。
多分計算は間違っていないはずだが、各自計算しなおしてもらいたい。
１秒以下の単位も計ることが出来るリアルタイムクロックを持っているコンピューターの場合は、もしかしたら doubleになっていて、計算もぜんぜん変わるかもしれないが、主なコンピューターの現在のアーキティクチャーはある基準時刻からの秒数になっていたはずだ。
この問題の重要な点は、コンピューターのハードウェアの問題ではなく、ＯＳを含むソフトウェア問題である点だ。
もちろんハードウェアの問題も大きいが、unixの時代からこういう計算方法を使用してきたＣ言語では、もし、標準関数（localtime()関数等）を使わずに秒をlongとして自分で計算していた場合、そのプログラムは２０３８年はじめには使えなくなる。
どの程度そういうプログラムがあるかわからないが、既に標準で関数があっても、自分で何でもやりたがるバカなプログラマーが作ったプログラムはすべて破綻する。
標準関数を使用していれば、time_t型がなんであろうと、最悪再コンパイルで何とかなるかもしれない。
ハードウェア的に万年カレンダーが組み込まれていてもどうしようもない。
ハードウェアの問題では、ワークステーションではほとんどブラックボックスになってしまっているが、パーソナルコンピューターの場合、BIOSが対応していない場合がほとんどである。各自の BIOSを見てもらえばわかると思うが、２０？？年で一周してしまうはずである。
これらを考えると、今回の２０００年問題と同様に、問題先送りをしてしまっているのではないだろうか？
まあ、そのころまで現在のアーキティクチャーのまま行くかどうかわからないが、２０００年問題も根本的な考え方は同様に「２０００年までには変わっているんちやうかな？」ということだったのではないだろうか。
これが４桁の西暦に対応しているが、処理系によっては問題が発生するということである。
２桁の西暦でやっているプログラムは、１０年以上前から既にわかっている問題を先送りしただけである。
なぜ２桁で処理していたかもわかる。
理由はほとんど金銭的（技術的）な問題である。
メモリも補助記憶装置（ＨＤＤ等）も高価な時代に、年を４桁も持っていたらいくらかかることか。
２桁なら、００〜９９までなので、２バイトですむところが、４桁の場合は、最低３バイト必要になる。
ビットで見れば２桁なら７ビット（１バイト弱）だが、４桁なら１４ビット（２バイト弱）必要になる。
データベースで見ると、１データに付き１バイト少なくなれば、１０万件なら約９８Ｋバイト、１００万件なら約９８０Ｋバイト、１０００万件なら約９．５Ｍバイトも節約できる。
昔の事情なら、現状必要ないなら無駄になってしまう。
ほんの十数年前は１０Ｍバイトのハードディスクが数十万したのだ。
そりゃあ、２桁で持っても仕方がない。
しかし、どんどん「バイト単価」は下がってきた。その間何もせずにそのまま使っていたのが悪い。と思う。
コンピューターが使われ始めたときに、時代の先端を狙って早くシステムを入れてしまったが、それからあまりバージョンアップをしていない企業などが困ったことになる可能性がある。
とまあ、いろいろ書いてきたが、ちゃんとしたＳＥやＰＧならこんなことは百も承知なので、２０００年問題をクリアした時点で、もろもろの処置が加えられていると信じたい。
すべてがすべてこのような問題をはらんでいるわけではないことも憶えていて欲しい。
２０００年問題や、２０？？年問題も、それを狙って一儲けたくらんでいる奴も多いので、気をつけよう。