此條目 可?照 英語維基百科 相應條目??充 。 ( 2020年7月29日 ) 若?熟悉?源?言和主?，??助 ?考外??基百科?充?目 。?勿直接提交机械??，也不要??不可?、低品??容。依 版??? ，?文需 在??摘要注明?源 ，或于????部?? {{ Translated page }} ??。

在?算机?用上， 2038年?? 可能??致某些?件在2038年1月19日3?14分07秒之后无法正常工作。所有使用 POSIX?? 表示??的程序都?受其影?，因???以自1970年1月1日??的秒?（忽略 ?秒 ）?表示?? ^[1] 。????表示法在 ?Unix （ Unix-like ）操作系?上是一??准，??影?以其 C?程?言 ???其他大部?操作系?使用的?件。在大部?的32位操作系?上，此「time_t」?据模式使用一?有正負號的32位元整數（signed int 32）存??算的秒?。依照此「time_t」?准，在此格式能被表示的最后??是2038年1月19日03:14:07，星期二（ UTC ）。超?此一瞬?，????“ ?回 ”（ wrap around ）且在?部被表示?一???，?造成程序无法工作，因???无法?此?????2038年，而可能?依個別實作而跳回 1970年 或 1901年 。因此可能?生??的?算及?作。

有少數的情況下，在制定規格時，特別規定以無正負號的32位元整數（unsigned int32）儲存POSIX??，因此錯誤會被延後到2106年。例如 比特幣 區塊? 中的區塊時間?記，就是以這種方法儲存。 ^{[2] [3]}

目前??有???有的 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）。

參考文獻 [ ?? ]

參見 [ ?? ]

• 2000年??
• 10000年??
• 民國百年蟲
• ??????
• UNIX??
• 2147483647 - 32位元表示的最大整數（以 2的補數法 表示）

外部連結 [ ?? ]

• Entry in How Stuff Works （ ?面存??? ，存于 互???案? ）
• The Project 2038 Frequently Asked Questions （ ?面存??? ，存于 互???案? ）
• Critical and Significant Dates 2038 （ ?面存??? ，存于 互???案? ）
• A 2038-safe replacement for time.h on 32 bit systems （ ?面存??? ，存于 互???案? ）
• The number glitch that can lead to catastrophe （ ?面存??? ，存于 互???案? ）
• Clewett, James. 2,147,483,647 ? The End of Time [Unix] . Numberphile. Brady Haran . [ 2019-04-06 ] . （ 原始?容 存?于2017-05-22）.