如何使用 Unix 時間戳記轉換器 – Epoch 轉日期線上工具
電腦不理解「2026 年 5 月 10 日下午 3:30」。它們理解數字——具體來說，是一個單一整數，計算自一個固定參考點以來的秒數（或毫秒數）。那個參考點是 Unix epoch：1970 年 1 月 1 日 00:00:00 UTC。數字 1751500800 對人類來說不像任何東西，但對電腦來說，它明確地代表一個精確的時間瞬間，獨立於時區、夏令時間轉換或日曆的奇特性。這種優雅的簡單性正是為什麼 Unix 時間戳記是軟體中主要的時間表示方式：它們出現在 API 回應中（created_at: 1751500800）、資料庫時間戳記欄位、日誌檔案（每行以前置 epoch 值開頭）、身份驗證權杖（JWT 中的 iat 和 exp 宣告），以及幾乎每個需要記錄何時發生事情的系統中。但當你需要除錯一個生產事件、閱讀稽核日誌，或驗證 API 回應是否包含正確的日期時，那些整數時間戳記就變成了一堵無意義的數字之牆。我們免費的時間戳記轉換器立即消除了這種摩擦。貼上任何 Unix 時間戳記——無論是以秒為單位（10 位數）、毫秒（13 位數），甚至是微秒（16 位數）——工具會顯示等效的人類可讀日期和時間，同時包含 UTC 和你的本地時區。ISO 8601 格式化輸出（例如 2026-05-10T15:30:00Z）可以直接放入任何 API 文件、測試夾具或資料庫查詢中。反向轉換同樣簡單：從日曆選擇器中選擇一個日期和時間，立即獲得對應的 Unix 時間戳記。每個計算都在你的瀏覽器中進行，無伺服器通訊，且工具處理許多轉換器會遺漏的邊緣情況：1970 年之前日期的負數時間戳記、32 位元系統的 2038 年問題，以及自動偵測秒、毫秒與微秒精度。
時間戳轉換器
免費 · 無需註冊
分步指南
貼上你的 Unix 時間戳記或從日曆中選擇日期
要將時間戳記轉換為人類可讀的日期，請將整數貼到輸入欄位中。工具會根據數字的大小自動偵測精度：10 位數（截至 2026 年約 1,000,000,000 到 2,000,000,000）被視為秒；13 位數（約 1,700,000,000,000 到 1,800,000,000,000）被視為毫秒；16 位數被視為微秒。這種自動偵測消除了「這個時間戳記是秒還是毫秒？」的猜測——這個問題已在生產系統中造成無數相差 1000 倍的錯誤。如果你有一個不尋常格式的時間戳記（例如，帶有小數毫秒的十進位秒數），工具會正確解析它並顯示精確時間，包括小數秒。要將日期轉換為時間戳記，請使用日期和時間選擇器選擇從公元 1000 年 1 月 1 日到公元 9999 年 12 月 31 日之間的任何日期。等效的 Unix 時間戳記會在你調整日期或時間時立即顯示。你也可以點擊「使用當前時間」以當前時刻填充選擇器，這對於為 API 測試請求產生時間戳記或檢查特定日誌條目是多久前建立的很有用。
以多種格式同時讀取轉換後的日期
工具以三種互補的格式顯示轉換結果，讓你可以精確挑選你需要的。首先，人類可讀的日期和時間以你的本地時區顯示——例如「2026 年 5 月 10 日星期日 下午 3:30:00 EDT」——並清楚標註 UTC 偏移量，因此對正在顯示哪個時區沒有模糊空間。其次，UTC 等效值並排顯示在旁邊，因為 UTC 是消除時區混淆的通用參考。並排顯示讓你可以立即驗證時間戳記是否符合預期：如果 API 說使用者是在 1751500800 建立的，而你的本地顯示是下午 3:30 但 UTC 顯示是下午 7:30，你就知道時間戳記是正確的，差異只是你的時區偏移。第三，ISO 8601 格式化字串顯示（例如 2026-05-10T15:30:00-04:00 或 UTC 為 2026-05-10T19:30:00Z），可立即用於 API、資料庫查詢或文件中。ISO 8601 是日期時間表示的國際標準，也是資料交換最安全的格式，因為它不含糊、可作為純文字排序，並包含時區資訊。相對時間描述——「3 小時前」、「2 天後」或「上週二」——讓你在無需心算的情況下立即獲得人類情境。
以你偏好的格式複製輸出或在你的程式碼中使用它
每種輸出格式都有其專屬的複製按鈕——點擊 Unix 時間戳記（10 位數秒）、毫秒時間戳記（13 位數）、ISO 8601 字串或人類可讀日期旁邊的按鈕，將該特定格式複製到你的剪貼簿。這讓你可以精確抓取你的程式碼、資料庫或文件所需的內容，而無需手動重新格式化任何東西。對於將時間戳記轉換整合到工作流程中的開發者，工具可作為產生測試資料的快速參考：想測試你的應用程式如何處理 30 天後的事件？選擇日期，複製對應的時間戳記，並將其插入你的測試資料庫。需要驗證 JWT 權杖的 exp 宣告（過期時間）尚未過期？貼上 exp 時間戳記並查看相對時間顯示——如果它顯示「5 分鐘後」，權杖仍然有效。對於日誌分析，從你的日誌檔案中貼上一系列時間戳記，以本地時間重建事件時間線，使關聯事件與特定使用者操作變得更容易。工具在編寫日期相關程式碼時也很有幫助：它讓你透過手動對照已知參考來驗證輸出，確認你的時間戳記到日期轉換是正確的。
使用技巧與最佳實踐
一個以秒為單位的 Unix 時間戳記從 2001 年 9 月到約 2286 年 11 月是 10 位數（涵蓋 285 年的跨度）。毫秒時間戳記在同一時期為 13 位數，並將持續到 2286 年。如果你的時間戳記是 10 位數，幾乎可以肯定是秒；13 位數表示毫秒；16 位數表示微秒。工具會自動為你偵測。
JavaScript 的 Date.now() 回傳毫秒精度的時間戳記（13 位數）。Python 的 time.time() 回傳帶有小數微秒的秒精度浮點數（例如 1751500800.123456）。了解你的語言回傳什麼，以避免在與其他系統整合時出現 1000 倍的錯誤。
始終在資料庫中以 UTC 儲存時間戳記。僅在顯示給使用者時在呈現層轉換為本地時間。這個單一實踐能防止大多數時區相關的生產錯誤——夏令時間轉換、跨時區移動的使用者，以及位於不同地理區域的伺服器，當你的標準資料是 UTC 時，這些都變成非問題。
ISO 8601 格式（2026-05-10T15:30:00Z）是 API 回應和資料交換最安全的選擇。它是人類可讀的、機器可解析的、時區明確的（Z = UTC，或像 -04:00 這樣的偏移量），並且作為純字串能正確排序。JSON Schema 和 OpenAPI 都推薦對日期時間欄位使用 ISO 8601。
2038 年問題影響 32 位元有號整數時間戳記：在 2038 年 1 月 19 日 03:14:07 UTC，值達到 2,147,483,647（最大 32 位元有號整數）並溢位為負數，導致日期跳回 1901 年 12 月。現代 64 位元系統免疫（它們可以表示 2920 億年後的日期），但嵌入式系統、舊版資料庫和較舊的 IoT 裝置可能仍使用 32 位元 time_t。如果你維護在 32 位元平台上使用 time_t 的 C/C++ 程式碼，計劃在 2038 年之前遷移到 64 位元。
負數時間戳記代表 Unix epoch（1970 年 1 月 1 日）之前的日期。例如，時間戳記 -1 對應於 1969 年 12 月 31 日 23:59:59 UTC。轉換器正確處理負數時間戳記，最早可追溯到公元 1000 年 1 月 1 日，這對歷史學家、檔案管理員和任何處理早於 Unix 時代的舊資料的人都很有用。
當比較來自不同系統的時間戳記時，務必檢查單位。一個系統可能以秒記錄，而另一個以毫秒記錄。時間戳記 1751500800（秒）是 2026 年 5 月 10 日，但 1751500800 被解釋為毫秒則僅為 1970 年 1 月 20 日——相差 56 年。如果轉換後的日期嚴重錯誤，除以或乘以 1000 作為第一個除錯步驟。
關於時區轉換：UTC 不遵守夏令時間。如果你的本地時間顯示與你的預期差一小時，你幾乎肯定是在看到 DST 效應。工具並排顯示 UTC 和本地時間，讓你可以立即識別 DST 相關的差異。例如，東部時間在標準時間（EST，11 月至 3 月）為 UTC-5，但在夏令時間（EDT，3 月至 11 月）為 UTC-4。
常見問題解答
Unix 時間戳記是軟體中時間表示的骨幹，但沒有可靠的轉換器它們是難以理解的。我們的免費工具即時在時間戳記和人類可讀日期之間進行轉換，自動處理秒/毫秒/微秒，並以 UTC 和你的本地時區顯示結果。它可以離線工作，保持你的資料私密，且無需帳號。為你的下一次日誌分析、API 除錯或資料庫查詢將其加入書籤。現在就試試：貼上任何 Unix 時間戳記，查看精確的日期和時間。
免費試用此工具 →open_in_new