“時間”不僅是中國古代詩歌的重要主題，在現代也頗受創作人的青睐。“盛年不重來，一日再難晨”，“時光一去永不回，往事只能回味”......這些朗朗上口的句子都告訴我們時間的河流只會向前奔湧，不會回頭。但是，其實現代技術存在的一個bug，能讓我們“時間倒流，回到過去。”
相信關注Linux的人應該都或多或少的聽說過2038年問題，下面筆者就先介紹一下什麼是2038問題。
如今，在手機和電腦上查看時間應該大多數人的習慣了吧。那你知道這些時間是怎麼計算得來的嗎?這就要追溯1970年，那時Unix被廣泛用於商業和學術界，所以1970年就被定位Unix和類Unix系統的元紀。所有系統的時間設定都以1970年1月1日0點0分0秒為基准，當前系統時間=基准時間+秒數。
從實施到現在，設備的系統時間一直都能穩定運行沒有出現差錯，但是機智的科學家還是從中發現了問題。在當時16位字寬已經很大了，32位在當時的人們看來已經是接近無限大了，所以time_t(也就是上述公式中的秒數)定義為32為有符號整數類型。也就是說在32位系統上，time_t最大值為0x7ffffffff，之後會溢出變成負值，再明白的一點說也就是2038-01-19 03:14:07之後就會發生時間倒流，我們將重回1901年。
其實這種時間和存儲之間產生的錯誤並不是第一次。為了節省空間，著名的女程序員Grace Hopper采用六位數來標記日期，隨著COBOL語言的不斷壯大，這種存儲方式的弊端就顯示出來了，後來居然發展成為了危害巨大的“千年蟲”。
為了解決這個問題，政府成立專門委員會，在確保關鍵基礎設施的情況下解決了這個問題。雖然從表面來看，2038與千年蟲很相似，但解決起來卻是更加棘手。
如果對用於存儲時間值的time_t數據類型的定義進行更改，則應用程序中依賴於帶符號32位time_t整數性質的一些代碼會出現兼容性問題。假設time_t的類型更改為無符號的32位整數，那麼治標不治本，這個問題仍會存在。
如果在64位架構的操作系統和程序中使用64位time_t整數，那麼系統時間可以從現在一直持續到292億年後。但是，如果粗暴進行，將會帶來嚴重性的後果。你可以想象一下，也許那時所有的應用程序都要重新編寫代碼，也許那一天所有的服務都會下線，你存在銀行和支付寶中的錢都可能會被清零......
對於Linux 2038導致的時光倒流你有哪些好的補救方法嗎?如果2038年真的“時光倒流”，想象一下那時的你會在做哪些事情?