開發者工具·Unix時間戳轉換器
off-by-1000 錯誤：當日期顯示一月 1970 或年份 56000 時
· 為什麼它很重要
時間戳 偵錯 開發人員工作流程
在預期的毫秒數中傳遞秒數（或相反）是最常見的時間戳錯誤。這篇文章展示了它在各個方向的外觀、它在不同語言之間隱藏的位置，以及如何在幾秒鐘內捕捉它。
每個使用者皆於 1 一月 1970 加入 — 洩漏錯誤的螢幕以及完全正確的後端
顯示 1 月 1970 附近每個帳戶的個人資料頁面是一個強烈的規模症狀。後端可能已傳回正確的紀元秒，而前端程式碼將它們直接傳遞給解釋毫秒的 Date 建構函式。然後，目前的計數在日曆軸上縮小了一千倍。
不要透過新增常數年份或取代日期來修補顯示。捕獲原始欄位、其 API 契約和確切的建構函數呼叫。 ToolAcre 可讓您強制使用兩種單位，因此可以在不更改生產資料的情況下測試一個值。與另一個已知事件相符的讀數識別出可能的邊界錯誤。
這兩個症狀 — 幾秒鐘的 API 在一月份 1970 著陸，幾毫秒的 API 在數萬年後著陸
秒被解釋為毫秒，接近紀元，因為十億毫秒只是一個世紀的一小部分。反向錯誤將萬億毫秒值擴展為萬億秒，通常超出了普通應用範圍。這兩種失敗都保留了數字，同時改變了它們的比例。
發表的十位數與十三位數的文章已經解釋了當代視覺啟發法及其局限性。本文的重點是診斷和預防：明確的單位選擇、獨立的事件證據以及生產者的表示滿足消費者的契約的介面上的一次轉換。
因為兩個分支都是確定性的，所以可以用一個夾具重現該症狀。這使得單位不匹配比間歇性時脈漂移或區域設定格式化行為更容易證明。
邊界通常在哪裡 — JavaScript 和 Java 以毫秒為單位，Unix 工具、Python 和大多數資料庫以秒為單位，以及它們之間的 JSON 有效負載
這個儲存庫證明 JavaScript Date 消耗毫秒，而 ToolAcre 在建構日期之前會乘以秒。它不會建立工作簿中指定的每個 Java、Python、shell 或資料庫 API 的預設值。必須在使用這些合約的地方進行檢查。
JSON 編號不攜帶單位元資料。將欄位命名為 `created_at` 會在服務之間傳遞歧義；將其命名為 `created_at_s` 或記錄 ISO 字串使合約可供審查。接收適配器應該將其轉換一次為其內部表示，而不是在視圖之間分散乘法。
在邊界定義旁邊編寫轉換，而不是在可重複使用的顯示助手中編寫。適配器知道生產者合約；通用格式化程序應該接收已經標準化的時刻。
單元邊界是 API 特定的；這個儲存庫證明 JavaScript Date 使用毫秒
諸如 `0` 之類的弱固定裝置無法檢測到該錯誤，因為零秒和零毫秒都命名了紀元。小的捏造值也可能看起來像是可信的 1970 日期。返回消費者期望的相同規模的模擬永遠不會出現真正的整合不匹配。
選擇一個非零已知時刻並使兩種解釋明顯不同。在邊界處斷言規範 ISO 結果，而不僅僅是 Date 物件存在。包括毫秒情況和秒情況； ToolAcre 自己的測試正是因為這個原因在每個單元下比較 1,000,000。
當測驗無法區分兩個尺度時，單元錯誤就會存在
考慮 `created_at: 1738578000`。強制為秒，則變成 `2025-02-03T10:20:00.000Z`；強制為毫秒，它變成 `1970-01-21T02:56:18.000Z`。已知於 2 月 2025 建立的部署記錄解決了歧義，而無需僅依賴數字計數。
在修復適配器時將原始 JSON 保留在已知事件旁邊。如果該欄位是 `1738578000000`，則毫秒解釋將識別相同時刻。儘管轉換器可以在應用正確的比例後證明它們的等效性，但絕不能在一個模式中互換地接受這兩個值。
已知的部署日期是獨立證據。如果沒有它，選擇更合理的產出可能會編碼調查人員的期望，而不是確定生產者的意圖。
工作範例：在兩個明確單位下測試created_at值
持久修復從邊界開始：解析記錄的來源單元，僅轉換一次並公開鍵入或明確命名的內部值。架構描述、範例和產生的用戶端應保留後綴或日期時間格式。然後，審閱者可以在執行之前發現額外的乘法。
加入具有實際比例和固定 ISO 期望的回歸夾具。當生產者有合約時，避免在應用程式程式碼中自動檢測；啟發式方法用於調查不確定的遺留資料。 ToolAcre 精確標記其偵測到的選擇，因此猜測無法偽裝成有保證的元資料。
這不包括什麼 - 時區錯誤，這會導致日期按小時而不是按幾十年移動
時區錯誤通常會使顯示移動幾個小時，並可能會跨越一個日曆日。 1,000 因子的錯誤會改變數十年或數千年。混合診斷會鼓勵圍繞已經錯誤的值進行偏移調整。在檢查本地格式之前驗證單位。
類似地，錯誤的紀元原點在秒和毫秒下仍然是無意義的。如果兩種解釋都不符合任何已知事件，請停止切換並調查生產者。轉換器縮小了假設範圍；它並不能證明每個大整數都是 Unix 時間。
如果年份可信，但時間始終錯位，則調查區域顯示。將這些症狀等級分開可以縮短從螢幕截圖到根本原因的路徑。
重點：錯誤的單位是錯誤的世紀 — 以及 Unix 時間戳轉換器的規定單位如何讓您立即測試兩個讀數
錯誤的單位不是裝飾性元資料－它會改變瞬間。將 1970 厚重的螢幕和難以置信的遙遠年份視為檢查生產者-消費者接縫的信號。價值、單位合約和已知事件構成了比表面上合理的日期更強有力的三部分證據。
使用轉換器比較明確讀數，然後在名稱、類型和測試中對所選標度進行編碼。我們的目標不是教軟體更聰明地猜測。它是從為用戶創建日期的路徑中刪除猜測。
代碼審查可以在每個邊界提出一個精確的問題：什麼單元進入，什麼單元離開？這比識別特定數量的數字更可靠。