2038 年可能是程式設計師面臨的一道坎，因為這關乎時間戳的問題。

文章選自維基百科：2000年問題和2038年問題，感興趣讀者可以自行閱讀英文版，資訊量更大一些。

2000 年問題

千年蟲問題，是指由於計算機程式設計的一些問題，使得計算機在處理2000年1月1日以後的日期和時間時，可能會出現不正確的操作，從而可能導致在2000年1月1日零點工作停頓甚至是發生災難性的結果。

一般來說，由於計算機程式中使用兩個數字來表示年份，如1998年被表示為98、1999年被表示為99，而2000年被表示為00。

這樣將會導致某些程式在計算時得到不正確的結果，如把“00”誤解為1900年。在嵌入式系統中可能存在同樣的問題，這有可能導致裝置停止運轉或者發生更加災難性的後果。

畫外音：這個對於我們程式設計師來說很好理解，有時候不知道業務發展會怎麼樣，基於資源和當時的發展情況來考慮，設定空間餘量不足，也是常有的事情。

2038年問題

UNIX作業系統是美國AT&T公司貝爾實驗室於1969年完成的作業系統，最早Ken Thompson、Dennis Ritchie、Douglas McIlroy於1969年在AT&T貝爾實驗室開發。

於1971年首次釋出，最初是完全用匯編語言編寫。後來在1973年用一個重要的開拓性的方法，Unix被丹尼斯·裡奇用程式語言C重新編寫，高階語言編寫的作業系統具有更佳的相容性，能更容易地移植到不同的計算機平臺。

#ifndef __TIME_T

#define __TIME_T

typedef long time_t;

#endif

在32位系統中time_t實際是一個4位元組的有符號長整型，其值表示為從UTC(coordinated universal time)時間1970年1月1日00時00分00秒到當前時刻的秒數。

由於time_t型別長度的限制，它所表示的時間不能晚於2038年1月19日03時14分07秒(UTC)，那麼當時間戳到達最大值2147483647會發生什麼呢？

畫外音：要理解2038年問題就必須要理解time_t和signed 32bit的計數。

2038-01-19 03:14:08

畫外音：這好像還是個大事情，一下子回到了1901年……

32位作業系統

在計算機應用上，2038年問題可能會導致某些軟體在2038年1月19日3時14分07秒之後無法正常工作。

所有使用POSIX時間表示時間的程式都將受其影響，因為它們以自1970年1月1日經過的秒數（忽略閏秒）來表示時間。

在大部分的32位作業系統上，time_t使用一個有正負號的32位有符號整數儲存計算的秒數。依照time_t標準，在此格式能被表示的最後時間是2038年1月19日03:14:07，星期二（UTC）。

一旦超過這個時刻，時間將會繞回且在內部被表示為一個負數，並造成程式無法工作，因為它們無法將此時間識別為2038年，而可能會依個別實現而跳回1970年或1901年。因此可能產生錯誤的計算及動作。

我們來看下官方的警告：

畫外音：官方警告最為真實…

64位作業系統

大部分64位作業系統已經把time_t這個系統變數改為64位，但是仍然有數以億計的32位系統在執行中，特別是許多嵌入式系統。

32位time_t的使用亦被編碼於檔案格式，例如眾所周知的ZIP檔案壓縮格式。其能存在的時間遠比受影響的機器長。

新的64位運算器可以記錄至約2900億年後的292,277,026,596年12月4日15:30:08，星期日（UTC），基本上可以徹底解決時間迴環問題。

畫外音:換了64位 舒服了…

2038年問題的影響

2038年問題與之前的千年蟲問題的殺傷力是不一樣的，千年蟲屬於應用程式的問題，而2038年問題卻是系統級的，有更大的殺傷力。

Linux Kernel 5.6 的開發者已經準備好著手解決將在下一個十年到來的 2038 年問題。Linux 5.6 也成為第一個為 32 位系統準備執行到 2038 年之後的主線核心。

至於像MySQL等元件同樣面臨2038年問題，目前還有17年的時候，我們相信可以應對這次危機。

畫外音:還有17年呢，說不定那會兒我都退休了，改造的事情交給年輕人吧…