Timestamps
為什麼首先會出現2038年問題？
我已經看到很多關於堆棧溢出的問題，關於為什麼某些程式碼在 2038 年之後無法使用，但答案通常只建議升級到 64 位作業系統。我的問題是為什麼首先會發生這種情況？它類似於 2000 年的問題嗎？是否可以使用不同的作業系統修復它，或者 32 位處理器在物理上無法處理超過 2038 年的時間？為什麼？（我是 linux 新手，所以這可能是一個簡單的問題，但我真的不知道答案）。
時間 un Unix 系統由自 1970 年 1 月 1 日 UTC 00:00 紀元以來的秒數跟踪。在 2038 年的某一時刻，該秒數將超過 32 位整數的儲存能力。這就是 64 位核心解決問題的原因。維基百科：
在許多平台上，表示時間點的 Unix time_t 數據類型是一個有符號整數，通常為 32 位（但見下文），直接編碼 Unix 時間編號，如前一節所述。32 位意味著它總共覆蓋了大約 136 年的範圍。最小可表示日期是星期五 1901-12-13，最大可表示日期是星期二 2038-01-19。UTC 2038-01-19 03:14:07 後一秒，此表示將溢出。預計這一里程碑將充滿樂趣和恐懼——參見 2038 年問題。
在一些較新的作業系統中，time_t 已擴大到 64 位。這將可表示的時間在兩個方向上擴展了大約 2930 億年，這是每個方向上宇宙目前年齡的 20 倍以上。
進一步閱讀這裡。