首頁 繪圖設計 工作閒聊 比賽活動 美術討論 標籤 圖片
2038 年 Overflow 問題簡單摘要 & 解決方式/解法 (2038/01/19)
Type(Type) 2015/1/31 15:04 (Since 2014/5/22 16:20)

UNIX TIME Overflow 2038 年問題簡單摘要 & 解決方式/解法





1. POSIX 標準 Unix time_t 是用 singled LONG

=> Linux/BSD/... 泛 UNIX 系統,目前都是這樣實做。


2. @ 64-bit Linux/Unix/BSD 這沒什麼問題

=> 9,223,372,036,854,775,808 秒 (2^64 / 2)
=> 約 292,471,208,677 年


3. @ 32-bit Linux/Unix/BSD 問題就來了

=> 2^32 / 2 = 4,294,967,296 / 2 = 2,147,483,648

=> 2,147,483,648 秒 => 約 68.09 年!


也就是從 1970/1/1 00:00:00 開始,到 2038/1/19 這一天系統時間就會錯誤,
變成又從 1970/01/01 00:00:00 開始


這和當初 1999 -> 2000 的「Y2K問題」,以及民國 99 -> 100 的「民國一百」問題很像
也就是用來儲存時間的欄位,2038 年會爆掉。


有人可能會問,
『現在 (2014) 離 2038 還有 24~25 年,到時候說不定 128bit 系統都普及了!』


不過要記住,很多
「現在設計的系統」「現在打上去的衛星」「現在設計的核電廠」「長期使用的銀行系統」
「今年設計的飛機 / 船隻」,他們的壽命通常是 25 ~ 50 年以上!

如果為了穩定、相容性等等因素考量,
很可能還是用 32-bit UNIX like OS / 32-bit Libraries / 32-bit chip (e.g. RTC real-time-clock) 等等
難免就會遇到此問題。


==============================================

解決方式:

1. 從現在開始慢慢使用 64-bit CPU/Chip/OS/Lib/Apps/FileSystem 設計部署你的系統。

2. 如果你的系統還沒上線,請做詳細 2038 年測試 ("Year 2038 Compliant Test") 。

3. 如果你的系統是自己從頭設計,
為了相容性,「metadata, data structure, database 等請勿使用 time_t」,
這很容易導致誤解和相容性錯誤,建議一律用「u64 or s64」!

4. 將你的系統做 19xx 年的判斷(前提是:假設你的系統沒有 19xx 年前的資料!)
例如:這個系統沒有 1980/12/31 以前的交易資料(這應該很可能),
所以可以多了約 10 年的緩衝

也就是大概是這樣子,看到 overflow 的數字,直接當成 2038/01/19 + Offset

1970/01/01 ==> 2038/01/20
1970/01/02 ==> 2038/01/21
1970/01/03 ==> 2038/01/22
...


pseudo code:
代碼:

     u64 check_and_remedy_timestamp(time_t __this_year_timestamp)
     {
          u64 __precise_timestamp = __this_year_timestamp;

     #ifdef CONFIG_2038_REMEDY
          if (__this_year_timestamp <= str_to_timestamp("1980/12/31"))
          {
              __precise_timestamp = do_some_timestamp_remedy(__this_year_timestamp);
          }
     return __precise_time;
     #endif /* CONFIG_2038_REMEDY */

     return __precise_time;
     }




5. 如果你無法變更你的系統,
或者根本沒有能力(或者時間)判斷、測試是否有此問題,

則請於 2038 年之前,慢慢淘汰您的系統! 然後您的新系統,必須符合第一點。




6. Q: Windows Server 使用者有 2038 年的問題嗎?

Ans: 不用擔心,NT Kernel 在十幾年前就用 64-bit 當成 timestamp,雖然單位是 100 nano seconds,
也大約要到西元 2184 年才會爆炸。


7. Q: Mac Server 使用者有 2038 年的問題嗎?

Ans: 不用擔心,有人實測過。 http://blog.interlinked.org/misc/2038.html


Type(Type) 2014/8/7 19:30

Linux Kernel 3.17 (@ 2014) 的 2038 年解法




增加一個 timespec64 structure, 其中 tv_sec 使用 time64_t (64-bits)


代碼:

struct timespec {
         __kernel_time_t   tv_sec;         /* seconds */
         long      tv_nsec;      /* nanoseconds */
};

struct timespec64 {
        time64_t   tv_sec;         /* seconds */
        long      tv_nsec;      /* nanoseconds */
};



(5,984 views)
[更多討論] 討論區 Windows, Linux, Perl, PHP, C/C++, Driver, Web 理論、應用、硬體、軟體




"2038 年 Overflow 問題簡單摘要 & 解決方式/解法 (2038/01/19)" 傳統頁面(電腦版)

首頁 繪圖設計 工作閒聊 比賽活動 美術討論 標籤 圖片
傳統桌面版 [ 登入/註冊 ]
© Vovo2000.com Mobile Version 小哈手機版 2019