繁體中文

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

閏秒和 Unix 時間:為什麼紀元假裝它們不存在

· 背景

時間戳 unix 時間 時區

時間軸直接從 23:59:59 到午夜
原始 ToolAcre 向量圖

UTC 自 1972 起插入了閏秒,但 Unix 時間根本不計算它們,這意味著有些秒發生了兩次。這篇文章解釋了為什麼、什麼是塗抹以及為什麼整個練習計畫結束。

第二個發生了兩次 - 一個系統中出現 23:59:60 ,另一個系統中出現重複的 23:59:59 ,以及午夜出現重複錯誤鍵

ToolAcre 無法產生以 `23:59:60` 結尾的 ISO 行。其測試命名了閏秒邊界,並期望一個紀元值格式為 `2016-12-31T23:59:59.000Z` ,下一個紀元值格式為 `2017-01-01T00:00:00.000Z` 。它們之間沒有額外的可顯示的秒數。

這一事實可能會影響外部來源使用其他約定的日誌,但此儲存庫不包含重複鍵事件證據。如果系統中出現重複的標籤,請檢查該時鐘和儲存路徑,而不是自動將它們歸因於轉換器。

因此,每個物理秒都需要唯一標籤的系統需要比 Unix-to-Date 映射更多的上下文。加工商無法製造其型號省略的標籤。

ToolAcre 證明沒有可代表的 23:59:60;它不記錄重複按鍵事件

該大綱解釋了原子時、地球自轉和容忍閾值。這些科學和標準宣告不是透過時間戳程式碼或測試建立的。它們是故意被遺漏的,而不是從記憶中轉述的。這裡的機制並不能證明全球計時政策背後的原因。

使用此路線所需的證據更簡單:日期和 ISO 輸出公開普通的第二個標籤,而 POSIX 風格的紀元跨越測試邊界前進。閏秒治理的源處理需要超出允許的儲存庫路徑的權威材料。

這個界限是明確的而不是迴避的:軟體測試回答代表性問題,而科學史需要為此目的編寫的材料並根據其自身的條件進行審查。

閏秒的物理原理需要此儲存庫以外的資源

實現的模型的行為就像其軸上的民用日具有 86,400 編號的 Unix 秒。連續的整數輸入相差一秒,包括跨越 2016 年邊界。 `fromEpoch` 將每個值乘以 1,000,然後日期格式化結果毫秒計數。

稱此為「忽略」閏秒描述了可觀察到的輸出:沒有唯一的 Unix 值對應到 `:60` 標籤。它並不意味著在實際插入過程中每個機器時鐘都以相同的速度前進。轉換器接受計數;它不會對主機時脈進行取樣或控制。

較大範圍內的算術遵循相同的約定,因此減去兩個 Unix 值可以測量它們的 POSIX 樣式計數差異,而不是重建省略的跳躍標籤。

測試的轉換在連續紀元值之間沒有閏秒標籤

系統可以應用步驟、重複或塗抹,但儲存庫無法辨識哪些提供者使用哪種方法、在什麼時間間隔或使用什麼公式。在沒有直接證據的情況下公佈這些細節將會造成操作上危險的精確性。因此,本文不做出特定於平台的時鐘承諾。

如果跳躍邊界附近的事件很重要,請保留來源的時鐘檔案和原始值。即使兩個值都格式化為 UTC 後,具有不同處理方式的兩個系統也可能會出現不一致。單獨的轉換不能協調它們的採樣行為或恢復被忽略的尺度區別。

執行時的選擇也會影響事件的短期排序。當這種差異在操作上很重要時,保留單調計數器或特定來源序列資料。

時脈步長和塗抹行為是特定於平台的,此處未經驗證

輸入 1,483,228,799 秒:驗證的 ISO 結果為 `2016-12-31T23:59:59.000Z`。將輸入增加一次至 1,483,228,800:結果為 `2017-01-01T00:00:00.000Z`。減去整數得到 1,與該模型中顯示的級數相符。

本機行可能會顯示不同的日期或偏移量,這取決於瀏覽器,但它們源自相同的時刻。使用 ISO 行進行邊界檢查。本地區域變化與閏秒標籤是否有無關。

該對是有用的回歸測試,因為 ISO 字串中不存在區域設定依賴性。它直接將轉換器的行為鎖定在相關邊緣。

工作範例:儲存庫經過測試的 2016 邊界

此工作簿引用了 2022 決議和未來的截止日期。實施證據中沒有標準或政策來源,因此此處既沒有宣告日期也沒有預測。計時政策可能會發生變化,並在出版時值得當前的權威引用。

省略該宣告不會削弱軟體指引。現有資料仍需記錄其規模、單位和時鐘來源。轉換器目前的行為仍然可以獨立於未來民用實踐的決策進行測試。

維護者可以稍後透過直接引用該決議來新增策略上下文。在那之前,排除最後期限比發布不受支援的未來保證更準確。

未來的政策決議在沒有權威來源的情況下被省略

TAI、GPS 和其他比例可以以不同的方式表示時間,但 ToolAcre 並沒有為它們提供選擇器或偏移表。將此類計數貼為 Unix 秒僅套用 1970 POSIX 風格的解釋。可讀的結果在語義上仍然可能是錯誤的。

使用在相關時刻定義其起源和關係的來源轉換其他比例,然後檢查產生的 Unix 值。不要加入記住的常數:涉及跳躍歷史的關係正是被動算術變得脆弱的地方。

在 UI 的三個單位選項中可以看到模式的缺失。沒有改變時間尺度;自動僅在兩個 Unix 解析度之間進行選擇。

其他時間尺度不在此 Unix 轉換器的實作範圍內

對於此轉換器,驗證規則是在測試邊界處從 23:59:59 到 00:00:00 的直接步驟。此模型支援普通的紀元演演算法,並解釋了為什麼沒有出現 `:60` 輸出。它不證明作業系統時鐘在實際邊界通過時的行為。

當精確度接近跳躍處理時,轉換是最後的呈現步驟,而不是證據來源。首先收集時脈尺度檔案、同步行為和原始事件欄位。然後,ToolAcre 可以顯示宣告的 Unix 計數在其測試模型下的意義。

對於遠離跳躍邊界的普通日誌,這種細微差別很少會改變顯示。然而,在敏感邊界附近,為模型命名可以防止物理秒保真度的虛假宣告。