什麼是2038年的問題？如何找出現有代碼是否存在這個問題並解決它？

可能重複：
What should we do to prepare for 2038?什麼是2038年的問題？如何找出現有代碼是否存在這個問題並解決它？

什麼是2038年的問題？

如何找出我們的代碼是否有這個問題並解決它？

2011-06-20 Jay

衆多上已經SO，例如重複[我們應該做什麼來準備2038？]（http://stackoverflow.com/questions/36239/what-should-we-do-to-prepare-for-2038）和[任何人都在做關於2038 time_t bug的任何事情？]（http://stackoverflow.com/questions/3918948/is-anybody-doing-anything-about-2038-time-t-bug） –

http://en.wikipedia.org/wiki/Year_2038_problem –

在C中，標準的4字節格式假定時間的開始時間是1970年1月1日上午12:00:00這個值是0.在它翻轉到負數之前的最大時間值無效）值爲2,147,483,647，即2038年1月19日。在此日期，任何使用標準時間庫的C程序將開始遇到日期計算問題。要糾正它，只需使用新版本的庫重新編譯程序使用8字節的值作爲存儲格式。

來源

2011-06-20 09:07:34 Balanivash

與8個字節，下一個問題何時出現？ – stijn

沒關係，明白了：http://www.merlyn.demon.co.uk/critdate.htm非常有趣的閱讀。看起來2100年將是2038年後的第二大年。 – stijn

我不認爲我們會在可預見的未來，有4個字節（e9），它已經持續了68年，現在有8個字節，可存儲秒數到e17。在一年內，我們有大約7秒鐘的時間，所以我認爲我們至少在9歲時是很好的:) – Balanivash

從00:00:00開始，以無符號整數形式存儲或使用系統時間的程序2038年1月19日，UTF將超出範圍。雖然大多數軟件在2038年都會遇到這個問題，但存儲未來日期的程序會受到影響。

解決方法將需要重新編譯（相關）代碼，以更大的存儲格式存儲時間。看似所有的編譯器提供商已經準備好了解決方案。

另外，64位操作系統已經對所有時間整數使用64位包裝器。這會使我們的危險遠遠超出我們的時間表。讓下一代人能夠找到更好的解決方案。

來源

2011-06-20 09:14:52 mihsathe

試試這個：如果第二行（和第三行）不在2038年，那麼你的系統有2038年的問題。

#include <stdio.h> 
#include <time.h> 

int main(void) { 
    time_t x; 

    x = (time_t)((1U << 31) - 1); 
    printf("%s\n", ctime(&x)); 
    x += 1; 
    printf("%s\n", ctime(&x)); 
    x += 1; 
    printf("%s\n", ctime(&x)); 

    return 0; 
}

代碼「運行」在ideone：有問題的系統
代碼「運行」在codepad：有問題的系統

來源

2011-06-20 09:27:59 pmg

什麼是2038年的問題？如何找出現有代碼是否存在這個問題並解決它？

回答

相關問題