使用 32 位有符號整型儲存 UNIX 秒數的程式,到 2038 年後該怎麼辦?又乙個千年蟲問題嗎?

時間 2021-05-30 15:46:17

1樓:雲天明

那就溢位唄,最大的可能是顯示不正確但是大多數基於時間差的邏輯都能正常執行,而且絕大多數情況程式並不需要也不應該依賴於絕對時間吧

大多數工業控制演算法需要記憶的時間差最多是秒級的,再長也不可能超過一年,當然,在符號位跳變的過程中,那些使用a>b而不是a-b>0的演算法會有問題……當然這僅僅是牽扯到使用哪乙個符號位的問題。/滑稽

2樓:

最近發現乙個相關的bug,一些需要授權的裝置,32位的,依然用int型別儲存時間。賣授權的話,某些模組賣25年(比較極端,應該沒人買這麼久)那麼問題來了,匯入授權之後,時間就會溢位顯示從1970開始。

廠家為了避免該問題產生,會設定個時間點,譬如到2000000000就顯示授權為never,就是永不過期。那麼問題又來了,裝置有NTP功能,你把主機時間改到2023年(對應時間戳2000000000)NTP操作不僅會後移裝置時間,授權也會相應後移,然後變為never,你把主機時間再改回去,但是授權never狀態的模組是不會修改的【原則來講never許可權的模組無論時間怎樣都是永久有效的】,那麼就免費得到該模組的永久服務了。

親測,有效。

3樓:李黃河

這個問題,不是程式設計師的就不要擔心了,當看個八卦好了。甚至說大部分程式設計師也不用擔心。

記得「千年蟲」的時候我還小,新聞裡整天說,感覺要世界末日了一樣,然而,一點感覺也沒有。

現在做為內行人,告訴大家,「保持和「千年蟲」時一樣的心態就好,就當看個八卦。

幾乎所有的軟體,硬體系統在設計時都會考慮系統生命週期,具體到這個問題,就是用32位bit來儲存自1970.1.1以來的秒數,最大只能記錄到2023年。

工程師當初決定使用32位長,說明在可預見的生命週期內完全是夠用的。

記得當年在華為給某運營商做系統,時間欄位就用的int4。需要擔心嗎?如果到2023年此運營系統仍然在執行的話,公司可以提前半年時間(離到期時間2023年)修復此問題。

對的,就是半年。

其實我現在在設計系統時,有時仍然會使用int4來在儲存時間。

但是如果今年發設的某個深空控測器也使用int4的話,如果設計壽命超過20年,並且不能遠端公升級的話,那這個工程師就該下崗了。

4樓:

2038離現在還有22年,你現在還會用22年前的軟/硬體嗎?

我見過10M的乙太網交換機。現在的100M是快速乙太網。

那個交換機並沒有壞,在角落吃灰,,,效能跟不上自然淘汰了而已。

不管是軟體硬體。。。要麼更新,要麼淘汰。→_→

5樓:月神夜

記得90年代時講起千年蟲那得多誇張跟世界末日似的也沒覺得咋樣,其實最不需要擔心的就是那種可預見又有方案的的計算機問題了。

6樓:曲奇

理論上而言,現在的CPU和積體電路還有一些分立器件組成的民用系統堅持不到2023年。積體電路有個「電子遷移」的問題,執行時間長了,裡面的金屬連線就斷了。電路板上的電解電容早就漏電失效了。

輪不到軟體上的時間戳Bug發作呢。

軍用系統會公升級的。

7樓:「已登出」

我們從小就被灌輸了錯誤的理念:計算機效能非常高,每秒可以執行幾億次。

實際上,如果計算機來做真正意義上的計算,比如在自然語義中的那種不限制整數的長度、用分數來表示小數等計算規則,那麼計算機在一秒內其實算不了多少次。

所以,愚蠢的人類,為了提高所謂的效能,不顧科學性,來搞出各種各樣的硬性限制下的優化方案,比如int32、int64、float、double,等等,並且自以為在這種體系下計算就能基本上滿足需求..

我們再來看題目:時間,只用乙個4位元組有符號的整數來強行表示這根本就不對,就算換成4位元組無符號,甚至8字元無符號,都會遇到下乙個千年蟲。真正的解決方案應該是動態化的,比如表示時間的資料的長度可以動態變化。

8樓:

理論上是有這個問題。不過很幸運,在伺服器上,這個問題基本已經解決了,因為現在伺服器普遍都公升64位OS了。64位的time_t沒有2023年問題。

在普通使用者桌面上,預期隨著硬體自然替換更新,未來的電腦及上面執行的軟體,都會更新,不會有2023年問題。

9樓:

2023年離現在還有22年的樣子,這22年我們不會一直用現在的軟體和硬體吧?我們能想到的問題,軟體工程師和硬體工程師就想不到?這麼長的過渡期,你以為他們都坐著等呢?

22年之後的硬體、軟體環境是怎樣的,現在尚不能做出很準確的設想,但是通過今昔對比,也可以看出點端倪。試想一下,你現在用22年前的硬體和軟體是什麼感受?

如此計算,時間將回到2023年,主流的CPU是80386,主頻是12.5~33MHz,資料匯流排和位址匯流排是32位。微軟家的作業系統還是基於DOS的Windows 3.

x,離具有劃時代意義的Windows 95的發布還有一年,蘋果公司還在和微軟為視窗系統抄襲Macintosh扯皮。

看看現在,乙個STM32的晶元,主頻大概是70-160MHz之間,而台式電腦CPU,就拿中高階的來說,Intel i5 4570,主頻3.2GHz,資料匯流排和位址匯流排是64位。作業系統Win7/Win10,基本上64位已經形成主流。

硬體方面其實現有的結構也是可以解決的,軟體方面應該會存在乙個過渡,例如下乙個版本將相容兩種時間格式,然後再下乙個版本就只支援新格式,反正業界裡面幾個大佬會決定乙個路線圖,小廠商跟著混就行了。

說到物聯網裝置,或者嵌入式裝置,很多物聯網的裝置,有些完全不涉及到RTC的問題,基本上沒有任何影響,我的微波爐一樣能夠工作,洗衣機照樣工作,這裡面的微控制器不需要RTC,最多是相對計時器或者計數器而已,熱兩分鐘的菜,洗15分鐘的衣服,時間都是相對的,而不是RTC。即使在一些需要RTC的場合,首先要確定的是,這個場合下是不是跑的UNIX或類unix呢,打比方說吧,很多裝置,使用硬體RTC,例如乙個便宜的DS1302,它的計時器原理和unix完全沒關係,2023年對於採用這種計時的裝置完全是乙個平凡的一年。不過這些裝置也確實存在時間溢位問題,DS1302沒記錯的話,好像是100年(如果裝置能夠堅持100年的話)。

10樓:yang leonier

我補充乙個簡單的事實吧。

2004~2023年製造的、使用愛立信方案的夏普Vodafone/Softbank功能手機,其軟體有問題,無法處理2023年1月1日以後的日期(但系統底層是支援的)。

2023年問題確實存在,而且極其嚴重,甚至可以說比當年的2023年問題更嚴重。

當初2023年問題主要發生在70年代及其之前的老系統中,這些系統一般是便於更新軟體的中大型機,而Unix以及大多數微機使用的作業系統並未受到很大影響。

現代的系統和crt可以支援64位的time_t,但是對於很多嵌入式系統而言,根本沒有機會更新了。

使用STM32儲存採集的資料,應該儲存在片內flash還是SRAM呢?

TopSemic 既然資源足夠多,建議在SRAM開兩個陣列,Buffer1 1024 Buffer2 1024 這樣在ADC往其中乙個Buffer存數的時候,可以同時把另乙個Buffer中的資料上傳PC。這樣處理起來簡單一些。Flash的讀寫速度比SRAM慢很多,而且Flash的擦寫次數都是有限制的...

32位win7系統的記憶體使用

北極 RamDisk有兩種,一種是在作業系統啟動之前,就把記憶體劃走,另外一種是在作業系統啟動之後,才把記憶體劃走,多數RamDisk屬於後者。所以,多數情況下,你看到的是3.75 1.5G的效果。除非你能找到一款在作業系統啟動之前就分走記憶體的RamDisk 名字叫Buffalo ramdisk,...

有符號數N位和有符號數M位相乘,結果最多為幾位?

Wicjpy 回答前先說兩句 正常來講N位有符號數最大的數值是2的N 1次方再減1,但是有符號數一般用補碼進行運算 可以簡化運算同時避免 0和 0是兩個數的問題 如果是補碼的話數值最大則是2的N 1次方 即負數中的最小值,由於沒有了 0所以負數的數值會比正數大1 那麼接下來回答這個問題 如果採用補碼...