如果你密切關注Linux領域的發展和動向，肯定了解2038年錯誤（Year2038 bug）。這個問題之所以會存在，是由於到了2038年1月19日那天，可以用Unix帶符號的32位整數時間格式表示的最新時間是03:14:07 UTC。之後，使用標準時間庫的C程式會開始遇到日期問題。

2000年問題又叫千年蟲或Y2K問題，這是與日曆日期的格式和儲存有關的計算機錯誤。這個問題之所以會出現，是由於早期計算機中的儲存空間很昂貴。於是，為了減少儲存空間，程式設計師使用了六位數的MMDDYY日期格式。由於程式能夠為年份YY新增19，它節省了資金，但縮減了檔案和資料庫的大小。然而，這種程式發現很難區別2000年、1900年和19100年。

為了解決這個問題，多國政府專門成立了委員會，確保關鍵基礎設施解決了這個問題。現在，類似的2038年問題成了全球計算機世界的另一個問題。

2038年問題又叫Unix千年臭蟲或Y2K38錯誤。在時間值以帶符號的32位整數來儲存或計算的資料儲存情況下，這個錯誤就有可能引發問題。

可以用Unix帶符號的32位整數時間格式來表示的最新時間是2038年1月19日03:14:07UTC，這是1970年1月1日之後過了2147483647秒。過了那個時間後，由於整數溢位，時間值將作為負數來儲存，系統會將日期讀為1901年12月13日，而不是2038年1月19日。

用簡單的語言來說，Unix機器最終將會耗盡儲存空間來列舉秒數。所以，到那一天，使用標準時間庫的C程式會開始出現日期問題。你可以在維基百科上詳細閱讀更多的相關內容（https://en.wikipedia.org/wiki/Year_2038_problem）。

下面這個動畫顯示了2038年錯誤將如何重置日期：

資料來源：維基百科

目前，2038年錯誤沒有什麼通行的解決方案。如果對用於儲存時間值的time_t資料型別的定義進行更改，依賴帶符號的32位time_t整數性質的應用程式就會出現一些程式碼相容性問題。假設time_t的型別被更改為不帶符號的32位整數，那將加大最新的時間限制。但是，這會對由負整數表示的1970年之前的日期造成混亂。

使用64位架構的作業系統和程式使用64位time_t整數。使用帶符號的64位值可以將日期延長至今後的2920億年。

已有人提出了許多建議，包括以帶符號的64位整數來儲存自某個時間點（1970年1月1日或2000年1月1日）以來的毫秒/微秒，以獲得至少30萬年的時間範圍。其他建議包括用新的庫重新編譯程式，等等。這方面的工作正在開展之中；據專家們聲稱，2038年問題解決起來應該不難。

文章來自微信公眾號：雲頭條