【Yahoo日本網站2025年1月報道】“2038年問題”是指到了2038年1月19日，32位計算機程序的時間戳，可能誤轉換為1901年12月13日。這是因為UNIX時間戳的初始時刻，是從1970年1月1日0點0分0秒，以秒為單位開始計時。至2038年1月19日12點14分7秒，表示日期、時間的值就會進入二進制的第32位。但是，由于第32位是表示符號的位，所以從1970年1月1日0點0分0秒開始被識別為“負2的31次方秒（約21億秒）”，也就是1901年12月13日20點45分52秒。
“UNIX時間戳”被廣泛用于嵌入式系統和控制系統的程序，不僅是表面的應用程序，還有中間件、OS、CPU等內部的系統也有進入的可能性。“2038年問題”有可能會對應用時間歷程進行控制的程序產生影響。
實際上，大約20年前的2004年1月11日，發生了關于2038年問題的糾紛。當時大型通信公司和SIer編制的程序發生了故障，造成大量的ATM停機。這是UNIX時間戳初始的1970年1月1日和UNIX時間戳迎來最大值的2038年1月19日的中間時刻，在通過“將兩個時刻相加除以2”求出某個時刻的程序中，2004年1月11日以后，兩個時刻的合計值進入了第32位。
鐵路等交通基礎設施、能源設施、各種工廠使用了很多嵌入式、控制系統。如果社會基礎設施一旦驟停，最壞的情況下，可能會造成生命和財產的重大損失。然而，準確判斷哪些系統會受到何種程度的影響是相當困難的。鐵路正在強勢發展的自動駕駛系統，極容易受嵌入式程序的影響，類似2038年問題對系統的干擾非常敏感。
為應對“2038年問題”最有效的方式是將32位系統更新到64位，64位UNIX時間戳的最大值是公歷約3000億年，可以半永久地表現時間。但這種方式并不簡單，UNIX時間戳可能存在于系統的深層，在很多共享的程序源代碼中已經埋下了“2038年問題”的隱患，溯源需要多少時間和預算及其他資源的投入，實在無法預估。此外，基礎設施的使用壽命一般都在10年以上，有的甚至達到20年、30年，因此更容易受到影響。
（來源：中國鐵道科學研究院集團有限公司科學技術信息研究所）
附件：