ＭＳさんちの２０３６年問題？！
1999.07.22
久々のコラムです。
世間ではいよいよ２０００年問題が 身近に差し迫り大騒ぎを始めていますが、２０３８年問題は ご存知でしょうか？
これは、ＡＮＳＩ−Ｃの時間関数が１９７０年１月１日 ００時００分００秒を基点として秒で表し、その値が３１ビット幅 あるため、２０３８年の途中でオーバーフローする問題です。
ＤＯＳ用のソフトやＵｎｉｘのソフトでは結構この時間関数を 使用した製品が多いため、今の２０００年問題とは比較にならないほど 大きな問題になると思うのですが．．．
さて、この２０３８年問題を調べているうちに、ＭＳさんちの 困ったローカルルール？が見つかりました。
それは、ＭＳ−Ｃ Ｖｅｒ７で作成したアプリでは、時間関数の仕様が異なっているため、 他のＣコンパイラ（Borland社等）とデータの互換性が取れないことが判りました。
どうも、ＡＮＳＩ-Ｃの１９７０年基点ではなく、１９００年を基点とした、３２ビット値となっているようです。
この仕様で行くと、２０３８年ではなく、２０３６年の途中でオーバーフローしてしまいます。
ＭＳさんもこの問題に気がついたらしく、ＶＣ Ｖｅｒ６では修正されていました。
ＭＳ−Ｃ、ＶＣの他のバージョンでは動作を確認していませんが、 ＭＳ−Ｃ Ｖｅｒ６のマニュアルではハッキリと、１９７０年が基点と 書いていました。
このコラムを見た方の中で、他社のコンパイラや、ＭＳ製の 他のバージョンのコンパイラについて追試をしてくださる方がいれば 幸いです。
今回の実験では、Ｋ島嬢に多大なご協力をいただきました。
この場を借りて感謝致します。
最後に試験プログラムのソースと試験結果を示します。
ソースコードはここ！
＜試験結果＞
１．Windows95のＤＯＳ窓で実行
Turbo C Version 2.0 Copyright (c) 1987, 1988 Borland International
>testtc2
Current date : 932430640 [3793C330H] -> Tue Jul 20 09:30:40 1999
Borland C++ 5.2 Copyright (c) 1987, 1997 Borland International
>testbcc5
Current date : 932430643 [3793C333H] -> Tue Jul 20 09:30:43 1999
msc V7
>testmsc7
Current date :
3141505836
[BB3F932CH] -> Tue Jul 20 09:30:36 1999
↑ここがおかしい。
VC Ver6
F:\temp\timefunc>testvc6
Current date : 932430646 [3793C336H] -> Tue Jul 20 09:30:46 1999
２．参考として、Ｕｎｉｘでも試験してみました。
Linux 2.0.36
gcc version 2.7.2.3
$ ./a.out
Current date : 932431119 [3793C50FH] -> Tue Jul 20 09:38:39 1999
ご意見ご感想は
webmaster@itofamily.com
まで
written by
