大膽預(yù)測2038年電腦公司問題始末

大膽預(yù)測2038年電腦公司問題始末

現(xiàn)在，由于受到媒體的廣泛關(guān)注，2000年問題已經(jīng)為大多數(shù)人所理解。

大多數(shù)以C編程語言編寫的程序基本不再受2000年問題的影響，但又受到了2038年問題的困擾。出現(xiàn)此問題的原因是，大多數(shù)C程序都使用稱為標準時間庫的例程庫。這個庫建立了一套用于存儲時間值的標準4字節(jié)格式，并提供了用于轉(zhuǎn)換、顯示和計算時間值的大量函數(shù)。

標準4字節(jié)格式假定：時間開始于1970年1月1日中午12:00:00。那一刻的時間值為0，任何時間/日期值都以該零值之后經(jīng)過的秒數(shù)來表示。所以，值919642718表示1970年1月1日中午12:00:00之后經(jīng)過了919,642,718秒，即太平洋時間（美國）的1999年2月21日星期日的16:18:38。這是一種方便的格式，因為只要將兩值相減，您就可以得到代表它們之間時間差的秒數(shù)。然后，您可以使用庫中的其他函數(shù)來確定這兩個時間之間相差多少分/小時/天/月/年。

如果讀過位與字節(jié)一文，您就會知道，帶有正負符號的4字節(jié)整數(shù)能夠表示的最大值是2,147,483,647，這就是2038年問題的源頭。在反轉(zhuǎn)成負值（因而無效）之前，時間的最大值是2,147,483,647，轉(zhuǎn)換過來就是2038年1月19日。在那一天，任何使用標準時間庫的C程序都將開始遇到日期計算方面的問題。

幸運的是，在大型機上，這個問題的解決要比2000年問題略微容易一些。編寫規(guī)范的程序只需使用新版本的庫（例如，使用8字節(jié)值的存儲格式）重新編譯一次就可以了。之所以能夠這樣解決此問題，是因為庫將整個時間活動和自己的時間類型與函數(shù)封裝在一起。這與多數(shù)大型機程序不同，那些程序沒有對自己的時間格式或計算進行標準化。所以，解決2038年問題就不會像解決2000年問題那么困難了。

一位思維敏捷的讀者善意地指出，IBM PC硬件會受到2116年問題的困擾。對于PC機來說，時間開始于1980年1月1日，并以無正負符號的32位整數(shù)的形式按秒遞增，這與UNIX時間非常類似。到2116年，這個整數(shù)將溢出。
Windows NT使用64位整數(shù)來計時。但是，它使用100納秒作為增量單位，且時間開始于1601年1月1日，所以NT將遇到2184年問題。

蘋果公司聲明，Mac在29,940年之前不會出現(xiàn)時間問題！