時間戳轉換工具：Unix時間戳與日期互轉（秒/毫秒，2026）
Unix時間戳轉換工具：時間戳與日期線上互轉，自動識別秒/毫秒級，實時顯示當前時間戳，並講清秒毫秒混淆、2038年問題等常見坑。
Unix時間戳轉換工具：時間戳與日期線上互轉，自動識別秒/毫秒級，實時顯示當前時間戳，並講清秒毫秒混淆、2038年問題等常見坑。
下面這個時間戳轉換工具，純瀏覽器本地執行，輸入即出結果，不上傳資料。往下有時間戳轉換的原理和使用說明。
一個 Unix 時間戳就是從 1970 年 1 月 1 日 00:00:00 UTC（這個起點叫"紀元 / epoch"）到某一刻所經過的秒數——它不帶時區、不帶年月日格式，只是一個整數。工具做的事分兩步：把整數按秒累加回紀元起點，得到一個絕對時刻；再按你選的時區，把這個時刻"翻譯"成人能讀的年月日時分秒。反過來輸入日期時，工具先按時區還原成 UTC 絕對時刻，再數出它距離紀元的秒數。
要抓住一個關鍵點：同一個時間戳，在北京和倫敦代表的是同一瞬間，只是顯示出來的鐘點不同。時區隻影響"怎麼顯示"，不改變時間戳本身。很多人以為換個時區數值會跟著變，這是最常見的誤解，也是排查跨時區 bug 時最先該排除的方向。
1. 秒和毫秒搞混。這是時間戳最高頻的 bug。JavaScript 的 Date.now()、Java 的 System.currentTimeMillis() 返回的是毫秒；而 Linux、多數後端 API、資料庫、以及 JWT 的 exp 過期欄位（RFC 7519 明確規定用秒）都是秒。把毫秒當秒傳，日期會飛到約 33000 年後；把秒當毫秒傳，日期會掉回 1970 年初。換算只有兩條：秒轉毫秒 ts * 1000，毫秒轉秒 Math.floor(ts / 1000)。
2. 2038 年問題。用 32 位有符號整數存的時間戳，最大隻能到 2,147,483,647 秒，對應 2038 年 1 月 19 日 03:14:07 UTC。再往後整數溢位，系統會把日期誤讀成 1901 年 12 月 13 日。解法是改用 64 位整數儲存，理論上能撐到約 2920 億年後。老舊嵌入式裝置、IoT 硬體、遺留資料庫是重災區，遷移時要專門盤一遍。
| 維度 | 秒級（約 10 位） | 毫秒級（約 13 位） |
|---|---|---|
| 典型來源 | Linux/Unix、多數後端 API、資料庫、JWT exp | JavaScript Date.now()、Java currentTimeMillis() |
| 示例數值 | 1711000000 | 1711000000000 |
| 用錯的後果 | 當毫秒用 → 日期掉回 1970 年初 | 當秒用 → 日期飛到約 33000 年後 |
換算時把這張表放手邊，先確認資料來源給的是秒還是毫秒，再決定要不要乘除 1000，基本就能繞開時間戳裡最坑的那幾處。