開發者工具·Unix時間戳轉換器
年 2038 問題：當 32 位元 time_t 溢出時會發生什麼
· 背景
時間戳 unix 時間 偵錯
在 19 一月 2038 的 03:14:07 UTC，有符號的 32 位到第二個計數器迴繞到 1901。這篇文章解釋了演演算法，其中 32 位元時間仍然隱藏，以及如何識別將受到影響的系統。
一個比聽起來更接近的日期 — 抵押貸款、證書和韌體已經計算出超過 2038 的日期
日期為 2038 的限制在計算超過該點的到期日、計畫或保留期限時都會影響程式碼。因此，故障可能會比時鐘日期早幾年出現。此儲存庫不記錄抵押、憑證或韌體產品，因此這些範例不會作為觀察案例呈現。
實際的稽核問題是是否有任何邊界將 Unix 秒儲存在帶符號的 32 位元整數中。成功格式化未來日期的現代瀏覽器並沒有說明下游欄位較窄。追蹤序列化和持久性，而不僅僅是用戶介面。
在今天的測試中搜尋未來日期的計算，而不是等待生產時脈。固定的邊界裝置將遙遠的日曆問題變成了即時的、可重複的檢查。
未來日期計算可以在 2038 之前暴露 32 位限制，但此處未證明指定行業
有符號的 32 位整數的最大值為 2³1−1 或 2,147,483,647。測試確定紀元後的許多秒為 `2038-01-19T03:14:07.000Z`。再數學一秒鐘應該是 03:14:08，ToolAcre 會顯示它，因為 JavaScript 數字和日期可以攜帶該值。
換行為負值需要外部有符號 32 位元操作； `fromEpoch` 不執行一項操作。經常被引用的 12 月 1901 結果可以透過補碼換行推匯出來，但聲稱每個受影響的系統都換行而不是拒絕、飽和或損壞將超出證據範圍。測試實際邊界。
如果外部轉換包含補碼算術，請檢查結果儲存的位元和解碼的負值。不要僅根據意外的歷史日期來推斷換行。
驗證準確的上限時刻；換行行為取決於外部整數運算
搜尋保存紀元秒的 32 位元簽章欄位的模式、協定定義和二進位佈局。名為 INTEGER 的 SQL 列不足以在所有引擎中提供足夠的證據，且內嵌平台不會自動受到影響。確定每個路徑的寬度、符號、單位和轉換代碼。
在審核中包含檔案和快取記錄。加寬的記憶體類型仍然可以寫入舊的窄格式，而寬資料庫可以接收截斷的客戶端值。在最大值和超出的值處建立固定裝置，然後檢查位元組或持久值，而不僅僅是檢查函數是否返回成功。
透過檢查實際模式和格式找到簽名的 32 位元紀元欄位
概念上的修復是一種表示，其範圍包括所需的日期，通常是更寬的有符號計數或適當的時間類型。工作簿的核心、libc 和格式遷移敘述位於這些來源檔案之外。每個系統都有自己的相容性和部署工作。
作為协调的合同變更來扩大每個邊界。在沒有線域的情況下更新存儲，或在沒有現有資料的情況下更新存儲，會留下狹窄的連結。在必要時添加版本控制並明確測試老讀者。紀元定義本身不需要改變；容器確實如此。
遷移計劃必須包括回滾和混合版本行為。在任何持久日期到達日曆邊界之前，產生寬值的新寫入器可能會破壞舊讀取器。
擴大代表性是核心解決方案；內核和格式遷移是特定於系統的
將2,147,483,647轉換為秒，得到`2038-01-19T03:14:07.000Z`；轉換 2,147,483,648 以獲得 `2038-01-19T03:14:08.000Z`。平滑的一秒鐘步驟證明 ToolAcre 路徑在該值處沒有 32 位元懸崖。
現在強制使用與毫秒相同的數字。它們落在 1970 一月，因為這些值在零後大約二十五天變成。這種比較可以防止單元錯誤被錯誤標記為 2038 問題。欄位寬度和比例是獨立的尺寸。
這種比較也說明了為什麼轉換器是診斷性的而不是易受攻擊的：明確的單位選擇決定了比例，而瀏覽器的更廣泛的表示形式包含這兩個值。
工作範例：轉換器跨越邊界，因為 JavaScript 日期未簽章 32 位元秒
此儲存庫也將 4,294,967,295 秒測試為 `2106-02-07T06:28:15.000Z`，最大無符號 32 位元計數。它不測試 GPS 週翻轉或指定帶符號的 64 位元毫秒懸崖，因此這些命名主題被省略而不是概括。
邊界分析應遵循所使用的確切類型。從有符號切換到無符號會向一個方向延伸，但會刪除負日期，但仍會建立上緣。更廣泛的簽名表示通常保留兩個方向，具體取決於消費者的日期範圍。
每個懸崖都需要從寬度、符號和單位中得出自己的推導。將不相關的翻轉分組在「2038」下會掩蓋哪個二進位欄位實際上需要變更。
測試無符號 32 位元邊界；其他命名的懸崖位於儲存庫證據之外
轉換器無法審核原始碼、二進位檔案、資料庫模式或已部署的裝置。它顯示了候選編號的含義並提供了用於測試的具體裝置。靜態搜尋、型式檢定、序列化測試和遷移演練必須確定產品是否安全。
不要關閉審核，因為瀏覽器正確呈現 2038。這僅驗證此瀏覽器路徑。端到端地遵循值，尤其是透過可能發生隱式縮小的語言綁定和舊格式。
在该跟踪中包含依赖項和供應商接口。應用程式來源可能使用寬類型，而本機庫或裝置協定無形中縮小了相同的值。
重點：紀元沒問題，問題是整數寬度 — 以及 Unix 時間戳轉換器如何讓您檢查 UTC 和本地時間的任何邊界值
年份 2038 問題是一個整數寬度邊界，而不是 Unix 紀元算術中的缺陷。 ToolAcre 兩側的成功轉換使這種分離變得可見。只有當外部系統的其中一個表示無法攜帶下一個計數時，外部系統才會失敗。
使用 2,147,483,647 和 2,147,483,648 作為相鄰測試向量，驗證精確的持久性以及檔案單元和符號性。每個邊界的證據都比所謂易受攻擊的技術的通用清單更有價值。
相鄰向量應該跨越真實的序列化路徑，而不僅僅是記憶體中的計算。這就是名義上加寬的應用程式可以顯示剩餘的狹窄接縫的地方。