Unix 時間戳轉換
免登入・本機計算・資料不上傳
Unix 時間戳（一串數字）跟日期時間雙向即時互換，預設顯示台北時間，也能切換其他時區。輸入任一邊，另一邊立刻算出來，同時顯示距離現在多久。
例：後端 log 或 API 回傳資料裡看到一串 1785110400 這種數字看不懂是什麼時候，貼進來就知道是台灣時間幾點；匯出的 CSV 裡常見這種時間戳欄位。
全程在你的瀏覽器本機計算，內容不會上傳到任何伺服器。
怎麼算的？
三個欄位（時間戳、日期時間、ISO 8601）背後對應同一個絕對時刻，改任何一邊都會立刻重算其他兩邊。 日期時間 → 時間戳這個方向刻意不用「用瀏覽器當地時區直接建構日期」的寫法（那種寫法在非台北時區的裝置上會算錯）， 而是用 Intl.DateTimeFormat 查出「某個絕對時刻在你選的時區會顯示成幾點」，反推校正回絕對時刻， 確保不管你的裝置本身時區設定是什麼，換算出來的台北時間都是正確的。
時間戳的秒／毫秒是依數值大小自動判斷（10 位數視為秒、13 位數視為毫秒），也可以手動鎖定單位避免極端情況誤判。 「距離現在」與 ISO 8601 都會隨你輸入的時刻自動更新。
資料來源與依據
- 時區換算使用瀏覽器內建的 Intl.DateTimeFormat 時區資料（IANA 時區資料庫），非寫死的固定時差表，自動反映夏令時間。
- 全程在你的瀏覽器本機計算，輸入內容不會傳送到伺服器或任何第三方。
- 工具邏輯最後更新於 2026-07。
最後核對日期：2026-07-27
常見問題
Unix 時間戳（timestamp）到底是什麼？
就是「從 1970 年 1 月 1 日 00:00:00（UTC 時間）到現在經過了幾秒」的一個數字，電腦系統很愛用這種方式記錄時間，因為單純比大小、算差幾天幾小時都很方便，不用管月份天數、閏年這些麻煩事。你在後端 log、資料庫、API 回傳資料裡看到一串像 1785110400 這樣的數字，很可能就是它。
為什麼是從 1970 年開始算，不是西元 0 年或別的年份？
這是電腦科學的歷史慣例：Unix 作業系統在 1970 年前後誕生，工程師當時就選了那個時間點當作「時間的原點（起算點）」，這個規則後來被幾乎所有程式語言和系統沿用至今，變成業界標準，沒有更深的道理，純粹是「大家都這樣約定」。
同一串數字，為什麼有時候看起來是 10 位數、有時候是 13 位數？
差在單位是「秒」還是「毫秒」（1 秒 = 1000 毫秒）。現在（2026 年前後）的秒數時間戳大約是 10 位數（1,7XX,XXX,XXX），毫秒時間戳則會多 3 位變成 13 位數，這個工具會自動依位數判斷，你也可以手動指定，避免自動判斷在極端情況猜錯。
為什麼要特別強調「台北時間」？時區有差那麼多嗎？
同一個時間戳數字，換算成「幾點幾分」在不同時區看起來完全不一樣——時間戳本身其實是跟時區無關的絕對時刻，「幾點」才是要換算的部分。這個工具預設用台北時間（UTC+8，全年固定、沒有夏令時間）顯示，是因為多數台灣使用者換算時間戳最終都是想知道「台灣時間幾點」，如果沒特別處理，很多工具會誤用瀏覽器或伺服器自己的時區，換算出來對不上，這是這類工具最常見的地雷之一，也可以在下拉選單切換成其他時區。
ISO 8601 格式是什麼？
一種國際標準的日期時間文字寫法，長得像 2026-07-27T08:00:00+08:00，好處是不會像「7/8/26」那樣讓人搞不清楚是月份在前還是日期在前（不同國家習慣不同），也把時區資訊直接寫進字串裡（結尾 +08:00 或 Z），常出現在 API 回傳資料、日誌檔裡。