ITCWIN95 は 最初のバージョンより、 “年”に関しては内部で４桁処理をしていますので、2000年問題は発生しないはずです。また、今日まで問題が起こったという報告はありません。。
ただし、お使いのパソコンの BIOS などが 2000年問題に対応してなければ、ITCWIN95 の動作は保証出来ません。
もう一つの 2000 年問題として、「2000年は閏年かどうか」って問題がありますが、こちらのほうも ITCWIN95 はちゃんとしたうるう年の処理をしてますので大丈夫でした。
現在の ITCWIN95 は日本時刻
2038年1月19日03時14分7秒 以降の時刻を扱えません
実は、2038年1月19日03時14分7秒に、Ｃ／Ｃ++言語で書かれコンパイルされた、時刻処理を 32-bit signed long で行うプログラムは、今のままでは使えなくなるのです。Windows だけじゃなく、UNIX 上で動くプログラムも同じです。（Ｍａｃ用のＣコンパイラに関しては無知 ^^;）
Ｃ言語での時刻データの基本は、time_t ですが、この変数には 1970年 1月 1日 00:00:00 GMT からの経過秒数が入るのです。で、time_t は多くの処理系では "signed long" すなわち “符号あり 32-bit 整数値” として処理されています。
“符号あり 32-bit 整数” で表現できる最大値は、0x7FFFFFFF (2,147,483,647) なのです。 time_t はこれ以上の数値を表すことが出来ません。time_t に 0x7FFFFFFF
が入る時刻、それが2038年1月19日03時14分7秒です。
この問題は ITCWIN95 に限らず、ＯＳを含む、Ｃ言語で時刻処理を行う、ほとんどすべてのプログラムで起こります。今の時点で思いつく対策は、ITCWIN95 のソースコードを 64-bit 以上の処理系（コンパイラ）で再コンパイルし、それを 64-bit（以上）を処理できるＯＳでお使いいただくしかありません。
それまでに long を 64-bit として扱うＣコンパイラが出現すればいいですけどね。（16-bit Ｃコンパイラも long を 32-bit として扱ってる）
プログラマ側で今すぐこの問題に対処出来ないのがはがゆいところです。全く不可能とは言わないけど…
以 上
|