認識 Unix 時間戳與如何轉換
為何 epoch 時間重要、秒與毫秒慣例如何一直咬工程師一口，以及如何把任意時間戳轉成可讀日期與時區。
為什麼重要
日誌工程師查「1735689600」為何觸發告警。那是 2025-01-01 00:00:00 UTC（秒）還是把毫秒當秒解成 1970-01-21？選錯事後檢討時間軸差 55 年。Unix 時間戳便於儲存與運算，對人類卻不友善；秒／毫秒慣例又因語言、資料庫、API 而異。可靠的轉換器會把單位說清楚。
三個實際場景
貼 1735689600，轉換器顯示 2025-01-01 00:00:00 UTC 與 2024-12-31 16:00:00 PST。選受影響使用者時區再往下查。
事件分流更快
輸入 JST 當地日期，複製結果 epoch（秒或毫秒依據你的排程器）。
程式里 epoch 正確
每行一個 epoch，旁邊顯示解碼後 UTC 日期，複製回試算表。
可讀報表
操作說明
開啟 Unix 時間戳轉換。
貼時間戳或選日期
轉換器自動判斷秒（約 10 位，1973–2286）或毫秒（13 位）。異常值可手動覆寫下拉選單。
讀多區解碼結果
UTC、瀏覽器本地，與任意 IANA 時區（如
Asia/Tokyo、America/Sao_Paulo）。反向：日期轉 epoch
在任一時區輸入日期時間；輸出秒與毫秒兩種 epoch。
依需求格式複製
1735689600、1735689600000、ISO2025-01-01T00:00:00Z、RFC 2822——選目的地接受的格式。
輸入
1735689600 (seconds)解碼（秒）
UTC: 2025-01-01 00:00:00
ISO: 2025-01-01T00:00:00.000Z
Local: 2024-12-31 19:00:00 (UTC-5)輸入
1735689600 (mistakenly read as milliseconds)誤當毫秒解
UTC: 1970-01-21 02:08:09.600
實用技巧
- API 合約務必寫明單位。 「Unix 時間戳」模稜兩可；「毫秒整數 Unix 時間戳」才明確。
- 負時間戳對 1970-01-01 前日期有效——轉換器接受並顯示正確格里曆日期。
- 給人看的顯示首選 ISO-8601。
2026-04-22T15:30:00Z無歧義且字串可排序。 - 整欄轉換可每行貼一個 epoch。
常見陷阱
常見陷阱
時區轉換後遇上 DST
十月太平洋 09:00 與十一月太平洋 09:00 不同，因 PDT 變 PST。請用 IANA 區（America/Los_Angeles）勿用固定 UTC-8，轉換器會套用 DST。
常見陷阱
JavaScript Date.getTime() vs Python time.time()
JS 回毫秒；Python 回秒加小數。移植程式請明確乘除 1000。轉換器兩種都吃，方便對照錯在哪。
常見陷阱
2038 年問題
部分舊系統用帶符號 32 位元存 Unix 時間。超過 2147483647（2038-01-19）會溢位。若維護此類系統請規劃升到 64 位元時間。
何時不適合用這套
- 營業日加減（如「從現在起五個工作天」）——用
date-fns-business-days或會計系統假日曆。 - Cron 排程除錯——用 cron 表達式工具列出接下來 N 次觸發。
- 行事曆週期（RRULE）——交給 iCalendar 解析器，不是單純秒數轉換。
FAQ
「epoch 零點」是哪一區？
0 是 1970-01-01 00:00:00 UTC。Unix epoch 定義以 UTC 為準。
為什麼一年有兩次時間會跳一小時？
日光節約時間。IANA 時區資料庫記錄各地規則，轉換器會自動套用。
輸入會送伺服器嗎？
不會。以瀏覽器內建 Date 與 Intl.DateTimeFormat 轉換；不離開頁面。
下一步
- 跨團隊開會窗用 時區比對工具。
- 常用城市加到 /time-tools/world-clock。
- 受影響地區今日是否放假：今日節日工具。