Y3Kとは違うだろソレ
いゃ、ソレY2Kとは根本的に違うから(^^;
Y2Kが問題になったのは、正常値を格納する領域が不足してたり、正常値の処理が正しく行えない(場合がある)という事であって、今回の問題は異常値の処理に問題があるという話。
言い換えると、設計当初「異常値である」とされた年限まで実際にそのシステムやデータが利用され続けてしまったというのがY2K問題の本質であって、その異常値に対する対処が正しく機能していなかったという問題ではない(まぁ、中には異常値の対処が正しくなかったシステムもあったかもしれないが、それは本質的な問題ではない)。
「西暦3000年を正常値として使うかもしれないのに、西暦3000年を異常値として処理するようになっている」という事を問題にするのであればY3K問題と言えるかもしれないけど、今回のはその異常値の処理が正しくないという問題なので、Y3Kというのは違うだろう。
2000年のY2K問題を彷彿とさせるこの不具合についてSANS Internet Storm Centerでは、日付に任意の制限を設けるのは良くないという、もう10年近くも前に業界が学んだ教訓が生かされていないと指摘している。
いゃ、指摘するのは簡単だけど、じゃあどうすれば良いの?
有限なメモリに格納する以上、どこかで制限を定める必要がある。
無限の年数なんてのは理論上は存在しても、コンピュータ上には存在し得ない。
そもそも、今回問題となった関数などが引数や戻り値として取るtime_tだって有限の値しか取らない。
関数の仕様が変わらない限り「任意の制限」は存在する。
今回の問題をY3Kと言うぐらいなら、これらtime_tという有限の値を使用する関数の存在そのものを「もう10年近くも前に業界が学んだ教訓が生かされていない」と言うべきじゃないだろうか?
ってか、1000年先の問題以前に32bit time_tによる2038年問題の方が焦眉の急だと思うんだが・・・
| 固定リンク
「パソコン・インターネット」カテゴリの記事
- LA2306xに替えてみた(2012.06.11)
- AdWordsのDM(2011.03.10)
- HDCS-U1.5R2買ってきた(2009.12.19)
- ストリートビュー、エリア拡大(2009.12.02)
- Amazon送料無料キャンペーン延長(2009.11.04)
この記事へのコメントは終了しました。
コメント