Unix 時間戳轉換工具

在 Unix 時間戳(紀元秒/毫秒)與可讀日期時間之間相互轉換。支援多個時區顯示、一鍵填入當前時間,以及相對時間顯示,專為開發者設計。

Unix 時間戳基礎知識

Unix 時間戳是以1970年1月1日 00:00:00 UTC(Unix 紀元)為起點、以經過的秒數來表示日期時間的一種方式。下表列出了一些具有代表性的時間戳數值及其對應的日期。

時間戳(秒) UTC 日期時間 備註
0 1970-01-01T00:00:00Z Unix 紀元(所有時間戳的起點)
1000000000 2001-09-09T01:46:40Z 時間戳達到10億秒的瞬間(Unix Billennium)
1234567890 2009-02-13T23:31:30Z 因數字恰好按1至9順序排列而被人津津樂道的數值
2147483647 2038-01-19T03:14:07Z 2038年問題:32位有符號整數所能表示的最大值(1秒後即發生溢位)

Unix 時間戳轉換工具是什麼

這項工具可以在 Unix 時間戳(紀元秒或紀元毫秒)與人類慣用的日期時間格式之間雙向轉換,並且完全在瀏覽器端完成運算,不會把任何資料送往伺服器。無論是在檢視伺服器日誌、對接 API 回傳的數值,還是確認資料庫欄位裡的一長串數字,都能立刻換算成看得懂的日期時間,或反過來把指定日期時間換算成程式可以直接使用的數值。

除了單純的雙向換算之外,工具也會一次列出 UTC、東京、紐約、洛杉磯、倫敦、巴黎六個時區在同一瞬間各自對應的日期時間,方便掌握跨時區團隊或伺服器所在地的實際時刻差異。輸入的時間戳若接近西元2038年1月19日 03:14:07 UTC 附近,換算結果也可能提醒使用者注意舊系統常見的溢位風險,這點會在下方的用語集與常見問題中詳細說明。

Unix 時間戳轉換工具的使用方式

  1. 選擇要進行的轉換方向 畫面分為「時間戳 → 日期」與「日期 → 時間戳」兩張卡片,依照手上資料的形式選擇對應的區塊即可,兩者互不影響、可以隨時切換使用。
  2. 貼上或輸入時間戳 在「時間戳 → 日期」欄位貼上數字(例如伺服器日誌裡的一串數值),單位預設為「自動判斷」,工具會依位數自動推測是秒還是毫秒,也可以手動指定。
  3. 確認換算結果與各時區對照表 轉換後會顯示 ISO 8601(UTC)字串、相對時間(例如「3小時前」)、以秒與毫秒表示的數值,以及六個時區的對照表,一次掌握所有需要的呈現方式。
  4. 或改由指定日期時間反推時間戳 在「日期 → 時間戳」欄位選好日期時間並指定所屬時區後,工具會自動處理夏令時間的偏移,正確算出對應的秒數與毫秒數,並拒絕像2月30日這類不存在的日期。
  5. 需要當下時刻時按一下「填入當前時間」 兩張卡片都提供「填入當前時間」按鈕,點選後會立即帶入瀏覽器當下的時間,省去手動查詢再輸入的步驟。

用好本工具的小技巧

  • 10位數通常代表"秒",13位數通常代表"毫秒"。選擇"自動判斷"即可根據位數自動推測單位。
  • 可以直接貼上伺服器日誌或API響應中的時間戳,一次性確認它在多個時區下對應的時間。
  • 在"日期→時間戳"轉換中,請務必明確選擇輸入日期時間所對應的時區。
  • ISO 8601(UTC)格式幾乎可以被所有程式語言和資料庫直接解析,在檢索日誌或設計API時非常實用。
  • 點選"填入當前時間"按鈕,即可立即從瀏覽器的 Date.now() 獲取當前時間並填入輸入框。

這個工具適合什麼場景

排查伺服器日誌

許多伺服器日誌只記錄一長串時間戳,把可疑的那一筆貼進工具,立刻能看出事發當下對應的實際日期時間,加快追查問題發生順序的速度。

開發與除錯 API

REST API 回傳的時間欄位經常是秒或毫秒的時間戳,開發時用這個工具反覆核對輸入輸出是否正確,能提早發現單位搞混或時區設定錯誤等常見錯誤。

檢查資料庫時間戳欄位

資料庫裡以整數儲存的建立時間、更新時間欄位不易直接判讀,取出可疑數值貼上轉換,能快速確認資料寫入的實際時間是否符合預期。

協調跨時區團隊的會議與排程

團隊成員分散在不同國家時,利用六個時區的對照表能一次看出同一個時間戳在各地分別是幾點,避免會議時間或發布排程因時差而喬錯。

產生測試資料與範例程式碼

撰寫單元測試或範例文件時,常需要一個明確、可重現的時間戳當作固定輸入,用「日期 → 時間戳」指定好日期時間即可直接取得數值貼入程式碼。

相關用語集

Unix 時間戳(紀元秒)
以 Unix 紀元為起點、經過的秒數所表示的日期時間數值,是電腦系統之間交換日期時間時最常見的表示法之一。
Unix 紀元
西元1970年1月1日 00:00:00 UTC,是計算所有 Unix 時間戳的起始基準點,本身對應的時間戳數值為 0。
UTC(世界協調時間)
不受任何地區日光節約時間影響的國際標準時間基準,Unix 時間戳一律以 UTC 為準進行計算,再依需要換算至各地時區。
紀元毫秒
以毫秒(千分之一秒)為單位的時間戳,數值恰為紀元秒乘以1000,常見於 JavaScript 等程式語言的內部時間表示。
ISO 8601
國際通用的日期時間字串格式(例如 2026-09-20T04:30:00Z),幾乎所有程式語言與資料庫都能直接解析,適合用來交換或記錄日期時間。
2038年問題
以32位有符號整數儲存時間戳的系統,會在西元2038年1月19日 03:14:07 UTC(即時間戳達到最大值 2,147,483,647 秒)後的下一秒發生數值溢位,導致日期錯誤地跳回1901年附近。
日光節約時間(DST,夏令時)
部分國家或地區在夏季將時鐘調快一小時以延長日照利用時間的制度,換算跨越調整日前後的日期時間時需特別留意時差變化。
相對時間
以「幾小時前」「幾天後」等相對於現在的說法來表示時間差,比起絕對的日期時間數字更直覺,常用於社群動態或通知訊息的顯示。

常見問題

Unix 時間戳(紀元時間)是以1970年1月1日 00:00:00 UTC(Unix 紀元)為起點、以經過的秒數來表示日期時間的方式。由於它用一個不依賴時區的單一數值即可唯一表示某個時刻,因此被廣泛用於伺服器日誌、資料庫、API 等計算機之間交換日期時間的標準方式。

2038年問題是指以32位有符號整數儲存 Unix 時間戳的系統,在2038年1月19日 03:14:07 UTC(最大值 2,147,483,647 秒)之後1秒會發生溢位,導致表示的日期倒退回1901年左右的故障。現代大多數系統已採用64位整數,不受此問題影響,但嵌入式裝置和舊系統仍需注意。

表示當前時代(2020年代至2030年代)的時間戳,若為秒單位通常約為10位數,若為毫秒單位則通常約為13位數。本工具的"自動判斷"模式正是利用這一位數差異來推測單位,但若要確保準確無誤,最可靠的方法仍是查閱原始資料的規格說明或API文件。

目前並沒有明確記載的單一原因,但普遍認為這與 Unix 系統本身誕生於1969年至1970年前後,以及這一整數年份便於當時計算機記憶體資源的處理有關。這個日期被稱為"Unix 紀元",此後幾乎被所有程式語言和作業系統沿用,成為事實上的標準。

負數表示1970年1月1日之前的日期時間。例如時間戳 -86400 對應的是1969年12月31日 00:00:00 UTC。在處理歷史日期或早於1970年出生日期等資料的系統中,有時會使用負數時間戳。
工具君

閒話 ― 為什麼計算機用"秒數"來計時

人類習慣用"2026年7月12日 17點8分"這樣年月日與時刻組合的方式表示日期時間,但對計算機來說這種格式並不友好:閏年、時區、夏令時等複雜規則每次都需要考慮,即便只是計算兩個日期之間的間隔也需要繁瑣的處理。於是人們想出了只用一個數值——距某個基準時刻經過的秒數——來表示時間的方法,這正是 Unix 時間戳。

將時間表示為單一整數值的最大優點,在於日期之間的比較與加減運算都可歸結為簡單的四則運算。要計算"兩個事件相隔多少秒",只需將兩個時間戳相減即可,完全不必顧慮閏年或每月天數不同的問題。正因為這種簡潔性,該格式不僅被類 Unix 系統採用,也被資料庫以及眾多程式語言的內部表示所採納,成為事實上的全球標準。另外,Windows 本身以 FILETIME(自 1601 年 1 月 1 日起的 100 奈秒單位)管理時間,但其 C 執行階段程式庫的 time_t 與 Unix 時間戳採用相同的格式。

另一方面,這種"不依賴時區的單一數值"的設計,也意味著時區轉換隻有在人類需要讀取它時才變得必要。同一個時間戳,在東京看可能是深夜,在紐約看則可能是前一天下午——顯示時所選的時區不同,看到的日期時間會截然不同。在排查日誌或除錯API對接時遇到的"時間對不上"這類令人困惑的故障,很多正是源於對這種時區轉換的疏忽。