時間工具 / 003
Unix 時間戳轉換
Unix 時間戳與日期時間雙向轉換，可辨識常見的秒與毫秒格式，並顯示本地時間、UTC 與 ISO 8601。
轉換完全在你的瀏覽器完成，貼上的內容不會傳送到任何伺服器。
為什麼做這個
API、資料庫與 log 常用 Unix 時間戳記錄時間，但一串數字不容易直接閱讀。這個工具可以在時間戳與日期時間之間雙向換算，方便除錯與整理資料。
這個工具怎麼用
Unix 時間戳是從 1970-01-01 00:00:00 UTC 起算的秒數，資料庫、API 與 log 常用它記錄時間，因為它只是一個數字，不受時區與格式影響。
把時間戳貼進上方欄位就會立即轉換。單位由位數自動判斷：10 位數當作秒、13 位數當作毫秒，所以從 log 複製出來的值可以直接貼，不必先想它是哪一種。
結果會同時給三種寫法。本地時間是你裝置時區的顯示值，適合對照人的作息；UTC 是國際標準時間，跨時區溝通時用它才不會有歧義；ISO 8601 則是程式之間傳遞時間的標準字串格式。
下半部可以反過來操作：挑一個日期時間，換回秒與毫秒兩種時間戳。要造測試資料、或把某個時間點寫進查詢條件時很好用。
記住幾個基準點就能快速判斷：`0` 是 1970-01-01 00:00:00 UTC；`1700000000` 是 2023-11-14 22:13:20 UTC，在台灣（UTC+8，不實施日光節約時間）則是 2023-11-15 06:13:20；`2147483647` 是 2038-01-19 03:14:07 UTC，也就是 32 位元有號整數能表示的最後一秒。拿到一個時間戳先數位數：10 位是秒、13 位是毫秒，再對照這幾個基準點，就能立刻知道它大約落在哪個年代。
排查時間相關問題時，最常見的錯誤是把毫秒當成秒（轉出來是幾萬年後）或把秒當成毫秒（轉出來是 1970 年 1 月）。其次是時區：資料庫與 API 通常存 UTC，畫面顯示才換成本地時間，同一個時間戳在台北與 UTC 的日期可能差一天。對帳或比對 log 時，請先統一用 UTC 比較。
實際走一次：`1759800000` 是 10 位數，當成秒，換算成 2025-10-07 01:20:00 UTC，台灣時間是同一天上午 09:20:00；貼 `1759800000000`（13 位數）會得到完全相同的時刻。如果少複製一位變成 `175980000000`（12 位數），工具會把它當成毫秒，結果跳到 1975 年 7 月——看到年份差了幾十年，先檢查是不是少貼或多貼了一位。
單位判斷的實際門檻是 12 位數：12 位以上當作毫秒，11 位以下當作秒。輸入只接受整數，Python 的 `time.time()` 這類帶小數點的秒數（例如 `1759800000.123`）要先把小數點後面去掉再貼。下半部的反向轉換以你裝置的時區解讀所選的日期時間，在台灣選「上午 9 點」得到的是 UTC 凌晨 1 點的時間戳。
常見問題
怎麼分辨時間戳的單位是秒還是毫秒？
看位數。以現在這個年代來說，秒是 10 位數、毫秒是 13 位數，差了一千倍。這個工具會自動判斷，但如果你拿到的是很久以前或很遙遠未來的時間，位數會不同，這時要自己確認來源用的是哪種單位。
為什麼轉出來的時間跟同事看到的差幾小時？
因為「本地時間」是依各自裝置的時區換算的。同一個時間戳在台北與倫敦會顯示不同的鐘點，但它們指的是同一個瞬間。跨時區對帳時請一律以 UTC 或 ISO 8601 那一欄為準。
2038 年問題會影響這個工具嗎？
不會。所謂 2038 年問題是舊系統用 32 位元整數存秒數導致的溢位，JavaScript 的數字型別遠大於此，本工具可以正常處理 2038 年之後的時間。要留意的是提供時間戳給你的那個系統。
貼進去的時間戳會被記錄嗎？
時間戳與日期的換算在目前頁面中完成，不需要把輸入值送到時間轉換 API。顯示結果仍會受到裝置時間、時區設定與瀏覽器時區資料影響。
時間戳轉出來是 1970 年 1 月，哪裡錯了？
通常是把以「秒」為單位的值當成「毫秒」解讀，或者拿到的值太小（例如 0 或空值被當成時間）。確認來源系統用的單位，再看位數是否為 10 位數或 13 位數。
帶小數點的時間戳可以轉嗎？
不行，這個工具只接受整數。帶小數的通常是「秒 ＋ 小數秒」（Python、部分資料庫會這樣輸出），把小數點後面去掉、用整數秒轉換即可，差距不到一秒。如果需要毫秒精度，可以把小數點去掉並補到 13 位，當成毫秒輸入。