爲什麼我們不使用完整的32位來存儲自Epoch以來的136年？

-2

我見過很多次，例如在UNIX上，在MySQL timestamp等：紀元開始於1970-1-1，但最高記錄的一年是2038年。現在讓我算：爲什麼我們不使用完整的32位來存儲自Epoch以來的136年？

2^32/60/60/24/365+1970 
2106

所以，如果我們使用完整的32位，我們自然會得到到2106年沒有任何問題。但顯然2038年只對應31位。那麼，爲什麼我們拋出一點呢？通過使用完整的32位，我們可以希望我們不必解決問題，因爲我們可能會首先摧毀地球......

對評論的反應：當然這是因爲它已簽名，但爲什麼會有時間戳必須簽字？這是這個問題的關鍵。

來源

2014-02-10 TMS

-1用來表示錯誤，所以我猜它必須簽名，並允許時間之前，1970年 – dalle

符號位允許負日期，即1970年之前 – 2014-02-10 19:07:53

@MikeW日期不MySQL，至少。你不能在時間戳中表示1970年之前的日期。 – TMS

這聽起來很瘋狂，但人們可能想要表示1970年之前的日期。切換對經典time_t值的解釋只會導致麻煩。

2038問題可以通過切換到具有相同規格的64位表示來側置。究竟應該如何進行是有爭議的，因爲能夠代表未來幾十億年的日期具有可疑價值，因爲這種精度可以用來代表亞秒級時間，但天真的解決方案比沒有什麼更好。

簡短的回答是：我們使用一個有符號的值，因爲這就是標準。

來源

2014-02-10 19:20:06 tadman

.. 。對於mysql而言，'DATETIME'是'TIMESTAMP'的替代品，可以處理更長的時間。 – admdrew

使用時間表示日期時，只能使用'DATETIME'方法。 'TIMESTAMP'值僅限於'time_t'範圍，並且有2038個限制，所以我強烈建議不要使用它們。這不是遙遠的，抽象的未來，距離它只有24年。 – tadman

同意。我必須仔細閱讀mysql文檔，才能明白爲什麼現在有人會使用'TIMESTAMP'。 – admdrew

這可能在「爲什麼time_t的簽署，而不是無符號」在這種情況下，你可能有興趣在聽到這背後這裏的原因屬於：

這裏原是一些爭論了Unix的time_t是否應該有符號或無符號。如果未簽名，未來的範圍將翻倍，推遲32位溢出（68年）。然而，這將是無法代表1970年以前的時間。丹尼斯里奇，當被問及有關這個問題時，說他沒有深入思考這個問題，但認爲有能力代表所有時間在他一生中會是不錯。（裏奇出生於1941年，Unix時間爲− 893 400 000.）共識是time_t被簽署，這是通常的做法。用於QNX操作系統版本6的軟件開發平臺具有無符號的32位time_t，儘管舊版本使用帶符號的類型。

來源

2014-02-10 20:04:09 user12321

你引用了任何特定的資源嗎？如果是，請包含指向它的鏈接。 – TMS

爲什麼我們不使用完整的32位來存儲自Epoch以來的136年？

回答

相關問題