2038 年問題詳解 — Unix 時間戳上限

邊界在哪裡？

32 位元有號整數範圍是 −2,147,483,648 到 2,147,483,647。解讀成 Unix 秒時，正數上限對應 2038-01-19T03:14:07Z；再加一秒就會在這種表示中溢位。

舊作業系統、嵌入式裝置、資料庫欄位和二進位協定仍可能使用 32 位元有號秒。64 位元時間戳或合適的日期類型能把實際邊界推到一般應用程式壽命之外，但必須確認完整資料鏈路都已升級。

應在邊界兩側選取數值，穿過解析器、儲存、API 序列化、用戶端執行環境和報表工具進行端到端測試。現代應用伺服器無法自動保護舊資料庫欄位或裝置協定。

也要檢查毫秒欄位的整數範圍、JavaScript 安全整數與第三方 API 的日期限制。不同單位與類型可能在不同年份到達邊界。

第三個值本身合法，只是超過帶正負號 32 位元整數的容量，並非 Unix 時間結束。可在時間戳轉日期工具手動選擇秒核對。

這類整數範圍為 −2,147,483,648 至 2,147,483,647。舊系統若溢位回繞而非拒絕寫入，下個值可能變成負數，顯示到 1901 年。實際行為取決於語言、作業系統與儲存方式。

檢查資料庫欄位、驅動程式、API 型別、序列化與應用變數。只擴大資料庫欄位，無法處理客戶端或嵌入式裝置仍強制轉成 32 位元整數的問題。測試邊界兩側，寫入後讀回並核對整數，不能只看格式化日期。

選擇整條資料路徑支援的寬整數或日期型別。無正負號的 32 位元秒數雖有較晚的上限，但不支援負日期，也未解決所有協定限制。

2038 問題針對帶正負號 32 位元的秒。JavaScript 安全整數上限與瀏覽器日期範圍是其他限制。同一時刻的毫秒、微秒、奈秒數值更大，不能因為還沒到 2038 就認為精度安全。

秒與毫秒指南說明單位；批次轉換器可檢查遷移檔案日期，但無法檢查或修改外部系統的資料型別。