Unix 時間戳是什麼？怎麼轉換成日期時間

一串看不出意義的數字

1735689600 是一個合法時間，1735689600000 也是。兩者相差 1000 倍，肉眼看不出差別——這正是第一個最容易踩的坑。

它們都是 Unix 時間戳：從 1970-01-01T00:00:00Z（epoch，紀元時間）起算經過的時間。資料庫存它、API 回傳它、日誌裡全是它，但人腦讀不了它。

知道規則之後就很簡單：

位數	單位	大致對應
10 位	秒	2001 → 2286 年
13 位	毫秒	同樣日期，數值 ×1000

JavaScript 的 Date.now() 回傳毫秒，多數後端語言與 Unix 指令回傳秒。這個不一致是經典 bug：毫秒值除以 1000 會得到 1970 年附近的日期，秒值當成毫秒用也一樣會落到 1970 年。

Unix 時間戳轉換工具會自動判斷位數，兩種都顯示。

時間戳本身沒有時區，它表示的是一個絕對時刻；是你的呈現方式帶了時區。

所以當時間戳「顯示成前一天」，問題幾乎總是：少了 Z、缺了時區位移，或者伺服器用本機時間格式化、而用戶端用 UTC 理解。

轉換工具會把 ISO 8601（UTC） 與本機時間兩行並排顯示，差異一眼可見。

資料庫：存 UTC，依使用者時區呈現。存本機時間是少數幾個很難挽回的日期決策之一。

日誌：請求旁邊那個 10 位數字，基本上就是秒級 epoch 時間。

API：看欄位名稱——created_at、createdAt、timestamp 常常是 epoch 值，但單位不能靠猜，看位數。

JavaScript 裡：

// 秒 → Date
new Date(1735689600 * 1000)

// 毫秒 → Date
new Date(1735689600000)

// Date → 秒
Math.floor(Date.now() / 1000)

單位混用：乘除 1000 只能做一次，多數 bug 是重複轉換造成的。
誤以為會解析成本機時間：new Date('2026-01-01') 依 UTC 解析，而 new Date('2026-01-01 00:00:00')（帶空格）在多數引擎裡依本機時間解析。
閏秒：Unix 時間本身就忽略閏秒，不要自作聰明去補。
2038 問題：32 位有號時間戳會在 2038-01-19 溢位，改用 64 位或毫秒可以避開。
負值：合法，代表 1970 年之前的日期。

偶爾驗證一次，瀏覽器主控台就夠了。但如果是反覆的工作——調 API、把日誌時間對應使用者回報、寫測試——一個能同時給出秒、毫秒、UTC、本機時間、星期與相對時間的工具會省下大量時間。試試時間戳轉換工具，它在瀏覽器本機執行，離線也能用。

時間戳帶時區嗎？ 不帶。它表示的是一個絕對時刻，時區只在你格式化它的時候才出現。

為什麼我轉換出來是 1970 年？ 幾乎可以確定是單位問題：把秒當成毫秒用了，或反過來。

ISO 8601 字串呢？ 那是人類可讀的替代方案（例如 2026-01-01T00:00:00Z）。自己設計 API 時建議採用，消費別人的 API 時兩種都要能接受。

時間戳可以是負數嗎？ 可以，代表 1970 年之前的日期。