是否有人在做關於2038 time_t bug的任何事情？

可能重複：
What should we do to prepare for 2038?是否有人在做關於2038 time_t bug的任何事情？

我不是指在抽象的 '人'。我的意思是你做任何事情，如果是的話是什麼？

我是一位古老的程序員，當我在70年代後期編寫COBOL時對我的團隊中的其他人說「你知道 - 這不會在2000年工作」。答案是「是的，但這個系統不會被使用，那是25年之後」。

2038年是28年。

2010-10-12 pm100

是2012年之後的2038年？是？首先，老兄。 – 2010-10-12 20:57:26

請將此設爲社區wiki問題。正確的答案可能是「我正在酗酒。」或者正確的答案可能是它是一個小操作系統問題。 Windows將會消失，64位Linux內核不會有這個問題。 – 2010-10-12 20:58:26

可能的重複：[我們應該做什麼準備2038？]（http://stackoverflow.com/questions/36239/what-should-we-do-to-prepare-for-2038） – 2010-10-12 20:59:03

我一個免責聲明添加到我的軟件的發行說明，上面寫着：Best before 2038.

2010-10-12 21:14:07 PeterK

祈禱和準備下一波昂貴的諮詢演出。正好趕上退休！

2010-10-12 20:56:59 kprobst

地獄是！每小時300美元來「修復」它。 – MattC 2010-10-12 20:58:21

@MattC，2038年300美元/小時可能是笨蛋的變化。現在，如果它是1975美元每小時300美元，現在我們正在談論。 – 2010-10-12 20:59:34

我認爲最簡單的方法是編寫易於維護的軟件。也就是說，數據模型和運算法則之間的耦合度較低。大多數DBMS和計算機語言已經被設計爲支持這種抽象。

2010-10-12 21:00:58 JPCF

當我需要存儲從紀元秒，我使用64位類型。如果我需要存儲時間戳和存儲空間不足，我將使用ISO-8601格式的字符串。

2010-10-12 21:05:24

許多系統使用64位time_t這不會換了很長一段時間（蜱=秒）。

在我自己的代碼中，我只是確保使用時間表示很長的時間，或者有時候做嵌入式的東西時，我只是設計一些東西，以便通過將時間計算限制爲相對較小（與可測量時間的長度相比）時間差值。

2010-10-12 21:15:16 nategoose

回答