別件を調べていたときに「2038年問題」というキーワードを知りました。
調べると2004年2月に日経コンピュータで特集されていたんですね。
その記事によると以下のようです。
UNIX環境では、システム内部の時刻をグリニッジ標準時（GMT）1970年1月1日0時0分0秒からの経過秒数で保持している。経過秒数で表す時刻データに、4バイトの符号付き整数を使っている場合には、2038年1月19日を過ぎると、本来数字の正負を判断するために使う部分まで時刻を表示するために使わざるを得なくなる。その結果、正しい時刻を認識できなくなるのである。
リンク：日経コンピュータ
この業界の方であれば、2000年の正月は大変だったと思います。前の会社でも上級職の方は交代で会社で留守番されていたのを覚えています。1999年は2000年を超えたときにシステムに何が起こりうるかシミュレーションを重ねていました。大変である一方、ビジネスにもなります。
まだ32年先ですが、まだ32年先だろう。。。という発想(下二桁で十分)が2000年問題を生んだとも言えます。しかし、先が長い話というのは私自身含めなかなか実感できませんね。やはり、短い時間で管理するのが大切だということなのでしょう。。。タクト方式（トヨタ生産方式）。脱線しました。
もう直ぐ64ビットCPUが主流になるでしょうから、ＯＳは問題なくなるでしょう。コンパイラもＣＰＵやＯＳに追従できる。やはり、問題なのは現行稼動しているアプリケーション資産。Javaであれば、JVMが対応すればいいのでプログラムを変更する必要性はないでしょう。2038年問題を見越してプログラムを作っているようなことがなければ。。。もし日付が1970なら2039にするとか。
リンク：２０ＸＸ年問題特集！
以下は間違いでした。ご指摘ありがとうございまいした。
以下、試しに、Javaで２０３８年問題を実感してみました。やはり１９７０年に戻ります。
■ソースプログラム（Test.java) 2038年問題
import java.util.*;class Test{
public static void main( String[] args ){
Date d = new Date(1000000);
System.out.println(d.toString() + "\n");
}
}■実行結果
Thu Jan 01 09:16:40 JST 1970
