2038年問題

在計算機應用上 ， 2038年問題可能會導致某些軟件在2038年1月19日3時14分07秒之後無法正常工作 。 所有使用POSIX時間表示時間的程序都將受其影響 ， 因爲它們以自1970年1月1日經過的秒數 （ 忽略閏秒 ） 來表示時間 。 這種時間表示法在類Unix  操作系統上是一個標準 ， 並會影響以其C編程語言開發給其他大部份操作系統使用的軟件 。 在大部份的32位操作系統上 ， 此 「 time_t 」 數據模式使用一個有正負號的32位元整數 （ signed int32 ） 存儲計算的秒數 。 依照此 「 time_t 」 標準 ， 在此格式能被表示的最後時間是2038年1月19日 03:14:07 ， 星期二 （ UTC ） 。 超過此一瞬間 ， 時間將會 “ 繞回 ”  且在內部被表示爲一個負數 ， 並造成程序無法工作 ， 因爲它們無法將此時間識別爲2038年 ， 而可能會依個別實作而跳回1970年或1901年 。 因此可能產生錯誤的計算及動作 。 有少數的情況下 ， 在制定規格時 ， 特別規定以無正負號的32位元整數 （ unsigned int32 ） 儲存 POSIX 時間 ， 因此錯誤會被延後到 2106 年 。 例如比特幣區塊鏈中的區塊時間戳記 ， 就是以這種方法儲存 。 目前並沒有針對現有的CPU ／ 操作系統搭配的簡單解決方案 。 直接將POSIX時間更改爲64位模式將會破壞對於軟件 、 數據存儲以及所有與二進制表示時間相關的部份的二進位兼容性 。 更改成無符號的32位整數則會影響許多與兩時間之差相關的程序 。 不過 ， 那時使用32位系統的計算機可能會很少 。 大部份64位操作系統已經把time_t這個系統變數改爲64位寬 。 不過 ， 其他現有架構的改動仍在進行中 ， 不過預期 「 應該可以在2038年前完成 」 。 然而 ， 直到2006年 ， 仍然有數以億計的32位系統在運行中 ， 特別是許多嵌入式系統 。 相對於一般電腦科技18至24個月的革命性更新 ， 嵌入式系統可能直至使用壽命終結都不會改變 。 32位time_t的使用亦被編碼於文件格式 ， 例如衆所周知的ZIP文件壓縮格式 。 其能存在的時間遠比受影響的機器長 。 新的64位運算器可以記錄至約2900億年後的 292,277,026,596 年12月4日 15:30:08 ， 星期日 （ UTC ） 。