Unix時間并沒有出現錯誤
1234567890是個節日, 一秒鐘的節日. 它不是問題, 不是錯誤, 不是BUG. 我們人類使用的計時系統是相當復雜的：秒是基本單位, 60秒為1分鐘, 60分鐘為1小時, 24小時是一天......如果計算機也使用相同的方式來計時, 那顯然就要用多個變量來分別存放年月日時分秒, 不停的進行進位運算, 而且還要處理偶爾的閏年和閏秒以及協調不同的時區. 基于"追求簡單"的設計理念, UNIX在內部采用了一種最簡單的計時方式：
計算從UNIX誕生[注釋1]的UTC時間1970年1月1日0時0分0秒起, 流逝的秒數. UTC時間1970年1月1日0時0分0秒就是UNIX時間0, UTC時間1970年1月2日0時0分0秒就是UNIX時間86400. 這個計時系統被所有的UNIX和UNIX-like系統繼承了下來, 而且影響了許多非UNIX系統. POSIX標準推出后, 這個時間也被稱為POSIX時間.
UNIX時間錯誤是誤解
可能是因為人類是一種需要精神上的刺激的生物吧, 各種歷法中都存在著各種擁有不同意義的節日. 其中, 很多節日僅僅由于日期的特殊性就被賦予了意義, 例如公歷1月1日的新年, 11月11日的光棍節，愛好節日的人們也沒有放過UNIX時間. UTC時間2001年9月9日1時46分40秒, UNIX時間迎來了第一個"億禧年"(Billennium)[注釋2], 1000000000. UTC時間2005年3月18日1時58分31秒則是UNIX時間的光棍節, 1111111111. 剛剛過去的1234567890, 對應公歷的UTC2009年2月13日23時31分30秒, 對東一區以東的時區來說是2月14日情人節, 以西的時區來說則剛好落在黑色星期五. 傳統上認為黑色星五不吉利的西方媒體, 針對此事進行了玩笑性的報道, 結果被一些居住在其他時區的人們誤讀成了"UNIX時間錯誤"。
丹麥哥本哈根的丹麥UNIX用戶群組織慶祝UNIX"億禧年" 圖為當時所用的倒計時公告牌
無獨有偶, 2012年7月13日也是一個黑色星期五, 而那天的UTC時間11時1分20秒對應著UNIX時間0x50000000(十六進制, 十進制值是1342177280). 不知到了那個時候, 會不會再次有人把它誤解為又一次的UNIX時間錯誤？
2038年的問題才是混亂
UTC時間2033年5月18日3時33分20秒, 是UNIX時間的第二個"億禧年"(Billenniumm), 即2000000000. 然而, 第三個"億禧年"(Billennium)則不會毫無障礙的來臨, 在那之前, 人們先得解決正在變得著名的2038年問題. 和本世紀初的千年蟲(Y2K Bug)問題類似, 2038年問題(Y2K38 BUG)更隱蔽, 而且更難解決. 我們知道計算機內部的一切都是二進制的, 也就是說1234567890在32位系統的內存里實際上是01001001 10010110 00000010 11010010. 這串32位二進制數中, 最高位被用來表示正負符號, 0代表整數, 1代表負數, 所以它能表示的最大數字就是01111111 11111111 11111111 11111111, 即214748367, 對應公歷的UTC時間2038年1月19日3時14分7秒. 到這天的凌晨3時14分8秒, UNIX時間會溢出并變成10000000 00000000 00000000 00000000(十進制值-214748368), 也就是UTC時間1901年12月13日20時45分52秒, 引起和千年蟲類似的混亂.
2038年問題的動畫演示
或許64位可以解決這個問題
2038年問題不僅比千年蟲更隱蔽, 而且它的原因也更接近系統底層. 要解決這個問題, 最簡單的方式是擴展UNIX時間的長度, 用64位數字來表示它. 64位二進制數的實際可用位數是63位, 最大表示到公歷的UTC時間292277026596年12月4日. 如果那個時候人類文明還存在的話, 公元紀年很可能已經因為太難用而被拋棄了. 理想的情況是到2038年, 64位系統已經成為主流, 從而避免特意去修正這個問題所需要的大量開銷. 否則, 人們就必須把新的64位時間拆分成兩部分并分別保存在兩個變量里, 這是一個麻煩而且效率低下的選擇.
[注釋1]: 就像很多其他的節日一樣, 把UNIX的誕生日選在這天只是出于方便. 實際上, 最早的運行在PDP-7上的UNIX在1969年就已經完成了.
[注釋2]: Billennium實際上是"十億禧年", 但是這樣聽起來很奇怪, 所以我用"億禧年"作為暫用名.
【編輯推薦】
