全球針對千禧蟲危機耗費數十億美元進行研究並更新電腦系統之後，其實還潛在另一個蟲蟲危機，Year 2038
程式錯誤預計將於該年度侵襲電腦使用者。更精確的說，2038 年 1 月 19 日星期二凌晨 3 點 14 分 07
秒的時候，受到這個程式錯誤影響的機器會將行事曆更改回 1901 年 12 月 13 日星期五晚上 20 點45 分 52 秒。
電腦工程師預測，這樣一來會導致作業系統和應用程式呈現錯誤且離譜的日期。很可能在許多平台上造成嚴重的問題，特別是 Unix、類似 Unix 和
Linux 平台，因為這些系統將「用完全部時間」。 他們不願預測損害範圍。
這個日期有什麼特別之處？原因是 Unix 和類似的作業系統並非依據格里高里曆(Gregorian calendar)
計算時間，而只是從任意的「生日」以秒計算時間，也就是 GMT (格林威治標準時間) 1970 年 1 月 1 日星期四 0 點0 分 0
秒。軟體程式設計人員認可的慣例是針對這個數字使用 32 位元的變數 (32-bit signed
time_t)。這個計算結果中結果整數可能的最大值為 2**31-1 = 2,147,483,647。因此，在 Unix
生日後的2,147,483,647 秒正好是 2038 年 1 月 19 日。而且一秒之後，Unix 系統理論上將回復成它們的出生日期
(就像里程表會從 999999 跳回 000000)。
專家認為，由於 Linux 因安全性和成本特性而有較廣泛的接受度，它的使用者所受到的災情將最為慘重。Linux 自己的 Y2K
惡夢比 Y2K 程式錯誤的殺傷力更大，因為後者基本上涉及應用程式，而 2038 程式錯誤則會影響本身的時間維持功能。 Linux
專家憂心這個程式錯誤對嵌入式領域的衝擊，這個領域更換軟體的狀況並不頻繁。因此，許多通訊小型工具與設備將逐漸受到影響。不過仍有一線希望在，也就是更
換 32 位元處理藉此克服程式錯誤的影響，但一定得在 2038 年之前完成。
可是，樂觀狀況僅止於此。這個程式錯誤會讓現在建立的紀錄過了 2038 年產生嚴重影響，例如保單。屆時，Unix 和 Linux 畫面上會出現錯誤訊息。而 Linux 近來逐漸成為普遍的作業系統。
專家表示，解決問題的速成方法就是更換成 64 位元或較長的 time_t 資料儲存裝置。可以更換一些既有的 32 位元程式碼並重新編譯程式。不過，這些都不是簡單的任務。
