2023年政策修订增补工作正在进行中,欢迎参与!
用戶:LJL/2038年計算機問題
< User:LJL
此頁面中存在需要長期更新的內容及資料列表,現存條目中資料未必是最新。
另請編輯者注意:請不要在人物歷程等相關內容中懸掛此模板。具體使用方法詳見模板說明文檔。
另請編輯者注意:請不要在人物歷程等相關內容中懸掛此模板。具體使用方法詳見模板說明文檔。
2038年計算機問題(Year 2038 problem) | |
---|---|
產生時間 | 2038年1月19日凌晨03:14:07(UTC) 2038年1月19日中午11:14:07(UTC+8) |
影響的系統 | 32位的計算機系統 如:安卓系統 基於32位的WindowsNT系統等 |
造成影響 | 系統崩潰,計算時間錯誤 |
類型 | 時間計算bug |
2038年問題 |
全球:UTC時間計算 -2038年01月19日03:14:07 |
- |
以GMT+8時間計算 |
2038年問題 |
全球:中國北京時間計算 -2038年01月19日11:14:07 |
- |
以GMT+8時間計算 |
概念
2038年問題是32位系統的最大的一個計算機時間計算機問題,類似於2000年的「千年蟲」問題。
主要的產生的現象是:到達指定的時間後,32位系統的時間計算由於受儲存器計算限制,導致時間重置為「0」(即恢復到開始的時間的計算時間點),然而這個「0」剛好是1970年1月1日0時0分0秒(UTC)
產生的原因
起因是源自32位的計算問題和時間的起點問題
32位的計算機本身可以計算時間的極限秒數為2147483647秒(忽略潤秒),當它計算到了最後一秒之後,無法繼續正數計算,變成負數,回到了32位計算時間的起點——1970年1月1日0分0秒(UTC)
然後計算機的各種網絡證書、電子簽名開始無效,導致計算機系統錯亂。
如果想更加的去了解這個內容,這就要涉及到C語言「標準時間庫」的問題,但是我不想深入介紹,有興趣可以看看度娘提供的說明。
解決辦法
目前來說最好的解決辦法是——換64位系統
目前對這個問題處理的話很難,需要將時間計算起點重新確定,但是一旦這麼修改,已經發佈的所有32位的程序必須要兼容這個計算起點,這個轉換時間非常漫長,很難處理。
所以從Windows2004版本開始不在發佈新的32位系統更新是對的qwq
愣着幹嘛?換電腦啊