開發者工具·Unix時間戳轉換器
瀏覽器如何使用 Date 和 Intl 將紀元轉換為本地時間
· 工作原理
時間戳 JavaScript 瀏覽器 API
瀏覽器轉換器沒有自己的伺服器時脈或時區資料庫；它依賴作業系統支援的 Date 物件和 Intl API。這篇文章解釋了管道及其局限性。
瀏覽器從哪裡取得「本地」？ — 同一時代在同一房間的筆記型電腦和手機上顯示不同
當配置的本地區域不同時，彼此相鄰的兩個裝置可以以不同的方式渲染一個紀元。筆記型電腦和手機之間的整數不變；每個瀏覽器建構相同的時刻，然後為其自己的環境提供本地日曆欄位。因此，「本地」描述的是讀者，而不是時代內部的財產。
ToolAcre 透過使用 `Intl.DateTimeFormat().resolvedOptions().timeZone` 標記本機行，使該依賴關係可見。顯示一個時鐘時間的螢幕截圖和顯示另一個時鐘時間的伺服器日誌可能都是忠實的讀數。首先比較它們的 UTC 行；匹配 UTC 輸出表示呈現不同，而不是底層瞬時不同。
Date 需要毫秒－建構子的約定，為什麼秒必須乘以千，以及 Date 可以表示的範圍
JavaScript `Date` 從紀元接收毫秒。 ToolAcre 的 `fromEpoch` 將秒輸入乘以 1,000 並在建構物件之前保持毫秒輸入不變。這個轉換是明確的，因為將 1,717,243,200 直接傳遞給 `new Date` 意味著 1970 之後大約二十天，而不是 6 月 2024。
實作在格式化之前拒絕非有限數字和任何超出 ±8.64×1015 毫秒的解釋值。此限制來自來源中指定的日期範圍，而不是來自資料庫或作業系統時鐘。更改選擇器可以將值移動到邊界之外，因此錯誤也會告訴您應用了哪個單位。
UTC 存取器與本機存取器 — getUTCHours 和 getHours，以及引擎如何套用偏移量
ToolAcre 不會提取帶有 `getUTCHours` 和 `getHours` 的欄位；大綱的存取器措詞比實作更具體。它要求 `Intl.DateTimeFormat` 使用 `timeZone: "UTC"` 格式化日期一次，並在沒有區域覆蓋的情況下格式化一次。兩個呼叫都接收相同的毫秒值，因此兩者都無法移動事件本身。
這種差異在偵錯時很重要。如果秒和毫秒行與生產者一致，但本地標籤讓您感到驚訝，請檢查瀏覽器區域，而不是向紀元添加小時。手動偏移算術將創建一個不同的時刻，然後讓格式化程式再次套用本機規則，從而產生經典的雙重調整錯誤。
UTC 和本地格式要求引擎提供一個日期的兩個讀數
轉換器可以證明它向瀏覽器請求 `resolvedOptions().timeZone`；它無法證明特定引擎是否從作業系統、捆綁資料或其他平台層取得了每個時區規則。來源故意將該機器視為引擎責任，如果區域查詢失敗，則返回到短語“本地時間”。
這個證據邊界很有用。結果中的命名區域標識了瀏覽器的目前選擇，但它不是時區資料庫的版本報告。如果兩個環境在舊日期上不一致，請記錄瀏覽器、作業系統和顯示區域。轉換器提供觀測值；它不會診斷 Intl 後面的資料包。
瀏覽器報告本地區域，而其規則來源仍然是實作細節
對於 ISO 行，`toISOString()` 提供具有尾隨 Z 和三個小數位的 UTC 字串。人類可讀的 UTC 和本地行使用英國英語格式化程序，其中包含數字年份、縮寫月份、兩位數日期和 24 小時時鐘。格式化程式也要求 `shortOffset`，使每個呈現行的適用偏移部分成為可能。
這些選擇解釋了為什麼從控制台複製 `Date.toString()` 不是等效證據。它的確切散文取決於語言環境，並超出了該工具的輸出合約。 ToolAcre 修復了其顯示選項，同時仍允許實際的本地區域變更。當另一個系統需要穩定的機器可讀比較時複製 ISO 值。
工作範例：一個紀元，三個輸出 - 一個 UTC ISO 字串、一個本地格式的時間以及與 getTimezoneOffset 的分鐘偏移量
輸入 1,717,243,200 並選擇秒。乘法產生 1,717,243,200,000 毫秒，測試將其確定為 `2024-06-01T12:00:00.000Z`。 UTC 行格式以 UTC 表示；本機行在瀏覽器區域中格式化相同的日期並命名該區域。秒和毫秒行保留兩種數字形式。
必須從執行範例的裝置讀取精確的本地時脈和偏移量；在這裡發布一篇文章會假裝每個讀者都有相同的區域。這就是為什麼此有效檢查使用 ISO 斷言作為其固定結果並將本地輸出視為觀察值的原因。如果 ISO 不同，請在調查位置設定之前重新造訪所選裝置。
工作範例：一個紀元，ToolAcre 實際公開的三個輸出
此路線不提供任意第三區域的選擇器。 `formatInZone` 可以在內部接受區域，但面板僅針對 UTC 和瀏覽器預設值呼叫它。一篇聲稱用戶可以選擇東京、內羅畢或多倫多的文章描述了一個尚未發布的介面，儘管 Intl 在其他地方可以支援此類格式。
它也不會公開日曆選擇、區域設定選擇或時區資料庫修訂。對於跨辦公室轉換，保留紀元作為錨點並使用其記錄介面命名目標區域的工具。在這裡，更狹隘的承諾是有價值的：本地環境旁邊的通用 UTC，沒有隱藏的伺服器來決定本地的含義。
重點：您的瀏覽器是時鐘和地圖集 — 以及 Unix 時間戳轉換器如何使用它在沒有伺服器的情況下並排顯示 UTC 和本地時間
瀏覽器既充當算術引擎又充當演示環境。 ToolAcre 解析單位，建立一個日期，請求規範的 ISO 值，然後並排格式化 UTC 和本機讀取。這些步驟不需要遠端轉換服務，且顯示的單位會保留 1,000 因子的決策可供審核。
當裝置之間的輸出不一致時，依序比較 ISO 行、單位註解和指定的本地區域。這三個觀察將即時、規模和呈現分開。將本地時鐘視為事實來源會將所有三個問題合併為一個，並每當觀看者改變區域時，正確的轉換就會顯得錯誤。