基本介紹
- 中文名：2038年問題
- 外文名：Year 2038 problem
- 概念：計算機bug（程式錯誤）
- 載體：使用POSIX時間的32位應用程式
- 爆發時間：2038年1月19日03:14:07（UTC）
32位時間表示,前言,正文,64位時間表示,解決進展,
32位時間表示
前言
在計算機套用上，2038年問題可能會導致某些軟體在2038年無法正常工作。所有使用POSIX時間表示時間的程式都將受其影響，因為它們的時間起點是格林尼治時間1970年1月1日0時0分0秒（這個時間名叫 the Unix Epoch），它們用the Unix Epoch經過的秒數（忽略閏秒）來表示時間。這種時間表示法在類Unix（Unix-like）作業系統上是一個標準，並會影響以其C程式語言開發給其他大部份作業系統使用的軟體。在大部分的32位作業系統上，此“time_t”數據模式使用一個有符號32位整數(signed int32)存儲計算的秒數。依照此“time_t”標準，在此格式能被表示的最後時間是第2147483647秒（代表格林尼治時間2038年1月19日凌晨03:14:07）。下一秒，即格林尼治時間2038年1月19日凌晨03:14:08，由於32位整型溢出，時間將會被“繞回”（wrap around）成一個負數，變成了第 -2147483648 秒（代表格林尼治時間1901年12月13日20:45:52），造成應用程式發生嚴重的時間錯誤，而無法運行。
2038年問題演示
2038年問題演示正文
也許大家都已經知道計算機的2000年問題是什麼概念，但是什麼時候又冒出來一個2038年問題的呢？
用C語言編制的程式不會碰到2000年問題，但是會有2038年問題。這是因為，大多數C語言程式都使用到一個叫做“標準時間庫”的程式庫，這個時間庫用一個標準的4位元組也就是32位的形式來儲存時間信息。
當初設計的時候，這個4位元組的時間格式把1970年1月1日凌晨0時0分0秒（這個時間名叫 the Unix Epoch）作為時間起點，這時的時間值為0。以後所有的時間都是從這個時間開始一秒一秒累積得來的。
比方說如果時間已經累積到了919642718這個數值，就是說這時距離 the Unix Epoch已經過去了919642718秒，換算一下就應該是1999年2月21日16時18分38秒。
這樣計算時間的好處在於，把任意兩個時間值相減之後，就可以很迅速地得到這兩個時間之間相差的秒數，然後你可以利用別的程式把它換算成明白易懂的年月日時分秒的形式。
要是你曾經讀過一點兒關於計算機方面的書，你就會知道一個4位元組也就是32位的存儲空間的最大值是2147483647，請注意！2038年問題的關鍵也就在這裡———當時間一秒一秒地跳完2147483647那驚心動魄的最後一秒後，你猜怎么樣？
答案是，它就會轉為負數也就是說時間無效。那一刻的準確的時間為2038年1月19日星期二凌晨03:14:07，之後所有用到這種“標準時間庫”的C語言程式都會碰到時間計算上的麻煩。
這就是2038年問題。
但是大家也不用太過緊張。2038年問題比千年蟲（the Millennium bug）問題解決起來相對要容易一些，只要給那些程式換一個新版本的“標準時間庫”就可以了，比如說，改用8位元組64位的形式來存儲時間。這樣做並不怎么費事，因為在C程式中“標準時間庫”是相對獨立的一個部分，裡面的時間表達都有自己的一套時間類型和參數（而在碰到Y2K的那些大型主機中，時間格式大都沒有一）。
說到這裡，一些冰雪聰明的菜鳥DDMM們應該可以聯想到，WindowsNT用的是64位操作平台，它的開始時間是1601年1月1日———但是它每過1個納秒就跳一下，因此，WindowsNT它會碰到的是2184年問題……
而在一些用64位來表示時間的平台上，例如DigitalAlpha、SGI、Sparc等等，想要看到它們的時間出錯你得等到天荒地老———那大概是2920億年。到那時，位於獵戶座旋臂的太陽，已經是黑矮星或暗黑物質，獵戶座旋臂已經被重力波震斷，銀河系大概則已經變成小型似星體了。
所以，給那些準備攢機的菜鳥DD一個建議，除非您想要把資料流傳給下一個宇宙，一台64位的電腦已經足夠。
總之，32位的最後時間是2038年1月19日03:14:07，星期二。
64位的最後時間約2900億年後的292,277,026,596年12月4日15:30:08，星期日。
64位時間表示
新的64位運算器可以記錄至約2900億年後的292,277,026,596年12月4日15:30:08，星期日（UTC）。
