開發者工具·Unix時間戳轉換器

微秒與奈秒紀元：縮短 16 和 19 數字值

2026年5月29日 · 工作原理

時間戳 unix 時間開發人員工作流程

某些運轉時以微秒或奈秒為單位發出紀元，給出秒或毫秒轉換器無法直接讀取的十六位或十九位數字值。這篇文章解釋了它們的來源以及如何安全地縮短它們。

追蹤中的十九位數字 — time.UnixNano 輸出貼到轉換器中，結果毫無意義

十九位追蹤欄位可以是納秒紀元，但將其直接貼到此轉換器中並不能檢驗該假設。 ToolAcre 接受秒或毫秒。它的範圍錯誤甚至暗示過大的資料庫數字可能使用微秒或奈秒，指導使用者在解釋之前進行標準化。

在調查時保留原文。將其轉換為普通的 JavaScript 數字已經可以在任何除法發生之前更改低位數數字。生產者的模式、日誌語句或資料庫列定義比視覺長度更好的證據，特別是對於根本不是 Unix 紀元的計數器。

秒每秒前進一次，毫秒快一千倍，微秒快一百萬倍，奈秒快十億倍。目前，這些數字通常顯示為十、十三、十六和十九個十進制數字。「經常」很重要：負號、較早的日期和較遠的範圍打破了僅限數字的規則。

面板的自動閾值僅區分 1011 等級的秒和毫秒。十六位微秒值超出該邊界，將被視為毫秒，通常超出預期日期一千倍。僅在將不支援的解析度減少為路線名稱之一後才選擇單位。

此大綱命名了多種語言 API 和儲存產品，但都不是該工具的來源檔案。不要假設哪個生產者發出了欄位，而是檢查其檔案。諸如 `_us` 或 `_ns` 之類的後綴、宣告的精度或已知的相鄰事件提供了十進制寬度無法提供的證據。

也區分紀元和單調持續時間。高解析度計數器可以測量自進程啟動或引導以來的時間，並與 1970 無關。除以這樣的值會產生較小的計數器，而不是日曆日期。在將結果傳送到紀元轉換器之前確認單位和原點。

若要將微秒減少到毫秒，請刪除 1,000 係數；對於奈秒，刪除 1,000,000。整數除法故意保留亞毫秒精度。對於正值，截斷採用前導毫秒計數。對於負數，選擇與產生器相符的捨入規則，而不是假設字串切片具有相同的語意。

當精確度很重要時，使用十進位文字或 BigInt 進行運算。浮點除法可以從已經四捨五入的十九位數字開始。如果調查需要一毫秒內的事件順序，則保留轉換時刻旁邊丟棄的餘數； ToolAcre 無法顯示這些亞毫秒級的差異。

將 `1738577696123456789` 視為奈秒。將其視為十進位文字，以整數算術除以 1,000,000，並獲得 1,738,577,696,123 毫秒，餘數為 456,789 奈秒。明確輸入毫秒商；其 ISO 讀數為 `2025-02-03T10:14:56.123Z`。

其餘部分不是噪音：兩個追蹤事件可以共享顯示的毫秒，但在其下方有所不同。儲存用於訂購的原始值，並僅將減少的輸出用於人性化。向上舍入到 1,738,577,696,124 會將顯示的時刻移動到下一個毫秒並錯誤地說明來源。

字串除法可以逐位查看：刪除的六位小數完全對應於奈秒到毫秒的刻度，而未更改的前綴仍然是日曆計數。

JavaScript 的精確整數保證遠低於典型的 19 位元紀元值。 ToolAcre 的解析器最終會呼叫 `Number`，因此透過面板輸入原始奈秒文字無法保留每個數字。它支援的日期限制和單位選擇器不會將 Number 轉換為奈秒整數容器。

使用 BigInt 或字串感知預處理路徑進行縮減，然後傳遞安全大小的毫秒結果。這種順序很重要：首先解析然後除法可能會精確地破壞您希望保留的數字。成功的日曆渲染並不能證明低階源值存活下來。

解析度告訴您表示可以區分值的精細程度；它不會告訴您時脈與物理時間有多接近。奈秒場可能源自不準確的來源，而秒場則可以很好地同步。該轉換器沒有時脈品質測量，也沒有做出這樣的宣告。

類似地，額外的數字可以填滿精度而不是測量精度。對於事件分析，使用同步證據比較時鐘，並使用原始記錄的計數器比較事件順序。日曆轉換僅提供可讀性。不要從長的小數尾或 ISO 中顯示的三毫秒來推斷精度。

在轉換前降低不支援的分辨率，保留原始分辨率，並說明丟棄的餘數。然後，ToolAcre 可以履行其合約承諾：讀取結果秒或毫秒，並顯示 UTC、本地和 ISO 格式以及所選單位可見。

如果標準化日期仍然沒有意義，請重新訪問原點而不是重複刪除數字。自啟動以來的計數器、另一個紀元或未記錄的編碼在任何規模上都可能保持錯誤。單位、原點和整數精確度是單獨的問題；在信任人類可讀的日期之前回答所有三個問題。

明確單位選擇器在歸約後很重要，因為自動偵測只是預設值。選擇毫秒記錄預處理決策，而不是要求幅度啟發式重新發現它。