Unix 時間戳記轉換
貼上時間戳或日期，得到其餘各種寫法。
什麼是 Unix 時間戳記
Unix 時間戳記（也叫 epoch 時間或 POSIX 時間）是從 1970 年 1 月 1 日 00:00:00 UTC 起經過的秒數（不計閏秒）。它是電腦儲存與交換時間點最常用的方式，因為它只是一個整數，不依賴時區、曆法或地區格式。資料庫、日誌、JWT 權杖、API 與作業系統都在用它，所以開發者總需要在 1700000000 這樣的原始數字和人能讀懂的日期之間來回轉換。
不同系統的精度不同。Unix 和大多數資料庫存的是秒（目前 10 位）。JavaScript 的 Date.now() 與 Java 的 System.currentTimeMillis() 回傳毫秒（13 位）。一些日誌系統和 Go 的 time 套件會提供微秒（16 位）或奈秒（19 位）。本工具依位數自動辨識單位，任何一種貼進來都不用手動選格式。
使用方法
頂部的即時時鐘每秒更新目前 Unix 時間戳記（秒），按「複製」直接取用，按「使用目前」把它填進轉換框。在輸入框貼上一個時間戳記，表格即時填入：秒、毫秒、ISO 8601（多數 API 使用的標準）、RFC 1123 格式的 UTC 字串、帶時區名稱的本地日期時間、「3 天後」「2 小時前」這類相對描述、星期幾、一年中的第幾天以及 ISO 週數。
反向同樣可用。輸入 2025-03-01、2025-03-01T14:30:00Z 或 March 1 2025 14:30 這樣的日期，會由瀏覽器的日期引擎解析並轉換為 epoch 秒與毫秒。沒有明確時區的日期依你的本地時區解釋，與 JavaScript 的行為完全一致。
時區、ISO 8601 與常見陷阱
時間戳記本身沒有時區，只有它的顯示形式才有。同一個 1700000000 在倫敦是 22:13，在台北是次日 06:13。當兩個系統的時間正好相差幾個小時，幾乎總是時區混淆造成的。系統間交換時間請優先使用帶明確 Z 或偏移量的 ISO 8601 字串（2024-11-14T22:13:20Z）或原始 epoch 數字，而不是本地日期串。另一個經典 bug 是把秒和毫秒搞混：看到 55000 年或 1970 年的日期，通常就是單位錯了，輸入框下方的「辨識為」提示會告訴你工具採用了哪個單位。最後別忘了 32 位元限制：用有號 32 位元整數存秒的系統會在 2038 年 1 月 19 日溢位。
背景：為什麼是 1970 年
Unix 紀元由貝爾實驗室的 Unix 開發者在 1970 年代初選定；第一版從 1971 年起以 1/60 秒計數，幾個月內就溢位了，於是改為從 1970 年 1 月 1 日起依整秒計數——一個安全地落在不久前的整日期。因為它忽略閏秒，每個 Unix 日恰好是 86,400 秒，算術變得極其簡單，這也是該格式從 Unix 擴散到所有資料庫、程式語言和網路協定的原因。2038 年問題（有號 32 位元計數器回繞）正是這一早期設計的直接遺產；現代系統用 64 位元儲存，未來 2920 億年內都安全。
應用領域
時間戳記是 JWT 權杖裡的 exp、iat、nbf 宣告，是幾乎所有資料庫的 created_at 欄位，是大多數日誌行的第一個欄位，也出現在 HTTP 快取標頭、cron 與排程系統、區塊鏈的區塊標頭、檔案系統中繼資料（mtime），以及決定 CDN 能否重用快取頁面的 ETag/Last-Modified 邏輯中。當工單裡寫著「匯出在 1718000000 失敗」，這個轉換器就是把它變成人類日曆上時間的方式；寫測試時，把一個固定日期轉成 epoch 秒，就得到了一個穩定、與時區無關的斷言值。本站的結構化資料以及你建構的任何 JSON API，都應該用 ISO 8601 字串保證可讀、用 epoch 整數做運算。
常見問題
怎麼取得目前的 Unix 時間戳記？
本頁頂部即時顯示。程式碼裡：shell 用 date +%s，JavaScript 用 Math.floor(Date.now()/1000)，Python 用 int(time.time())。
時間戳記是秒還是毫秒？
10 位是秒，13 位是毫秒。工具依長度自動辨識，並告訴你採用了哪個單位。
本地時間用的是哪個時區？
你瀏覽器的時區，顯示在時鐘旁邊。UTC 與 ISO 8601 兩列始終是 UTC，可以安全地貼到其他系統。
為什麼我的日期差了一天？
不帶時間和時區的日期串會依本地零點解析，轉成 UTC 後可能跨過日期邊界。用明確的時間與時區（如 2025-03-01T00:00:00Z）即可避免歧義。
支援負數時間戳記和 1970 年以前的日期嗎？
支援。負數從紀元往回數，例如 -86400 是 1969 年 12 月 31 日。