開發者工具·Unix時間戳轉換器
秒還是毫秒？区分 10 位纪元和 13 位纪元
· 工作原理
時間戳 Unix 時間 開發人員工作流程
您今天遇到的大多數紀元值要么是十位數字（秒），要么是十三位數字（毫秒），猜錯了會導致日期落後數萬年。這篇文章解釋了數字計數背後的算術，以及為什麼轉換器應該聲明單位而不是推斷單位。
1700000000 還是 1700000000000？ —同一時刻有兩種寫法，儀表板顯示遙遠未來的日期
日誌值 1700000000 和負載值 1700000000000 可以描述同一時刻。將第一個視為毫秒，您的儀表板將落入 1970 年 1 月；將秒視為秒，其日期會跳到數千年後的未來。時間戳只是一個計數加上一個單位和起點，因此沒有文件的名為created_at的資料庫列省略了重要資訊。
為什麼目前的秒數有十位數——2001 年是十億秒，十位數範圍一直到 2286，以及九位數意味著什麼
Unix 時間依照通常的 POSIX 約定計算從 1970-01-01 00:00:00 UTC 起經過的秒數。 2001年，該數字突破10億大關；對於當代的正日期，它通常是十位數小數。它保持十位數字，直到 2286 年達到 100 億。這是十進位表示法的屬性，而不是 ISO 日期字串中的規則。紀元之前的負值和遠遠超出目前的日期會使簡單的數字計數捷徑無效。
為什麼毫秒計數有十三——一千的因數，三位額外的數字，以及 JavaScript 和 Java 的約定的來源
JavaScript Date.getTime() 依照慣例計算毫秒，將秒時間戳記乘以 1,000。三個零使目前的十位數秒計數變成十三位數毫秒計數。例如 1,700,000,000 秒變為 1,700,000,000,000 毫秒；皆為 2023-11-14T22:13:20.000Z。僅插入分隔符號而不說明假定單位的轉換器可能會將有效數字轉換為看似合理但錯誤的日期。
猜測出錯的地方 — 紀元附近的小值、2001 年之前的日期以及數字計數不再區分的未來日期
在 1970 年左右，當毫秒值可能很短時，啟發式方法會失敗；在 2001 年之前，當秒數少於十位數時，或使用微秒和奈秒計數器時，啟發式方法會失敗。 ToolAcre 預設將低於 10^1 的量級解釋為秒，將較大的值解釋為毫秒，並標記所使用的單位。該閾值是實際的猜測，而不是明確的格式解碼器。特定 API 提供的時間戳記應使用該 API 的文件進行解釋，即使其長度不常見。
工作範例：一個日誌中的三個值 — 1700000000、1700000000000 和 1700000000000000，以秒、毫秒和微秒為單位讀取
說明性日誌中的三個整數顯示了該陷阱。將 1700000000 解釋為秒，將 1700000000000 解釋為毫秒：兩者都解析為 2023-11-14T22:13:20Z。將 1700000000000000 解釋為微秒並除以一百萬以獲得相同的秒數。 ToolAcre 轉換器接受秒或毫秒，而不是微秒模式：貼上第三個數字而不先轉換其單位將無法確認預期的時刻。調試時始終將原始字段及其單元放在一起。
為什麼應該說明單位，而不是猜測單位 - 轉換器如何顯示它所應用的單位，以便錯誤的假設是可見的而不是沉默的
發送時間戳的服務應在其架構中命名該單元或使用具有明確偏移量的 ISO 8601 文字。如果遺留欄位未記錄，請在做出決定之前將多個值與另一個可靠事件時間進行比較；單一的巧合可信日期不足以作為證據。轉換器會顯示它所應用的單位，讓您有機會發現 1,000 倍的錯誤。明確更改單位並進行比較，而不是依賴自動猜測作為長期 API 合約。
這不包括 - 以字串形式儲存的時間戳、ISO 8601 文字或電子表格序列日期，這是不同的問題
本文不解釋 Excel 序列日期、2026-09-28T10:15Z 等字串或本地時鐘讀取的時區格式。這些是不同的表示。 Unix時間戳指的是一個瞬間；同一時刻在不同區域顯示為不同的掛鐘時間。閏秒約定也值得單獨處理，並且 32 位元有符號計數器在 2038 年有溢位問題，這與秒與毫秒的問題不同。
重點：計算數字，然後確認單位——以及 Unix 時間戳轉換器如何讀取帶有單位標記的秒和毫秒
計算數字作為初始提示，然後確認生產者規定的單位和至少一個已知事件。 Unix 時間戳轉換器使應用程式的秒/毫秒假設可見，並在瀏覽器中列印 UTC 和本機表示形式。不要讓看起來整潔的日期覆蓋產生該值的系統中相反的文件。