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秒後即發生溢位） |
使用小貼士
- 10位數通常代表"秒"，13位數通常代表"毫秒"。選擇"自動判斷"即可根據位數自動推測單位。
- 可以直接貼上伺服器日誌或API響應中的時間戳，一次性確認它在多個時區下對應的時間。
- 在"日期→時間戳"轉換中，請務必明確選擇輸入日期時間所對應的時區。
- ISO 8601（UTC）格式幾乎可以被所有程式語言和資料庫直接解析，在檢索日誌或設計API時非常實用。
- 點選"填入當前時間"按鈕，即可立即從瀏覽器的 Date.now() 獲取當前時間並填入輸入框。
常見問題
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、資料庫以及眾多程式語言的內部表示所採納，成為事實上的全球標準。
另一方面，這種"不依賴時區的單一數值"的設計，也意味著時區轉換隻有在人類需要讀取它時才變得必要。同一個時間戳，在東京看可能是深夜，在紐約看則可能是前一天下午——顯示時所選的時區不同，看到的日期時間會截然不同。在排查日誌或除錯API對接時遇到的"時間對不上"這類令人困惑的故障，很多正是源於對這種時區轉換的疏忽。