時間戳轉換工具
Unix 時間戳與日期時間格式互相轉換
時間戳轉日期
日期轉時間戳
全球時區對比
常用格式範例
什麼是時間戳？
時間戳（Timestamp）是表示特定時間的數字值。Unix 時間戳是從 1970年1月1日00:00:00 UTC（稱為 Unix 紀元）到指定時間所經過的秒數。它是計算機系統中表示時間的標準方式，具有跨平臺、跨時區一致的特點。時間戳分為秒級（10位數字）和毫秒級（13位數字），秒級時間戳常用於 Unix/Linux 系統，毫秒級常用於 JavaScript 等程式設計語言。
使用方式
時間戳記轉日期
- 在左側卡片中輸入 Unix 時間戳記
- 選擇目標時區（例如：北京時間 UTC+8）
- 點選「轉換」按鈕查看轉換後的日期時間
- 結果包含：標準格式、ISO 8601、中文格式等
日期轉時間戳記
- 在右側卡片中選擇日期與時間
- 選擇該日期時間所使用的來源時區
- 點選「轉換」按鈕取得 Unix 時間戳記
- 結果包含秒與毫秒時間戳記
時區小提示
- 請確認原始數值是使用秒或毫秒；混用 10 位數與 13 位數的時間戳記是造成日期錯誤的常見原因。
- 轉換人可讀日期時，務必確認預期的時區，特別是在處理日誌、排程任務與跨區域系統時。
使用場景
技術原理
Unix 時間戳計算自 Unix 紀元以來經過的時間，該紀元定義為 1970-01-01T00:00:00Z，是 POSIX 時間用來標記其後所有時刻的零點。POSIX 時間刻意忽略閏秒：每個日曆日被視為恰好 86,400 秒，因此跨越閏秒插入的兩個時間戳與嚴格的原子鐘計數會有一秒的偏差，但權衡之下，紀元秒與 UTC 日曆欄位之間的轉換始終是乾淨的 86,400 取模運算。 日常最常見的兩種格式是秒級（目前為 10 位數字，例如 1717000000）和毫秒級（13 位數字，例如 1717000000000）。JavaScript 的 Date.now() 返回自紀元以來的毫秒數，`new Date(ms)` 接受毫秒數，而 Unix 的 `date +%s`、Go 的 time.Unix 以及大多數資料庫的 TIMESTAMP 欄位使用秒數。基於長度的偵測是常用的消歧方式：10 位數值作為秒數解讀時落在 2001-2286 年範圍內，而相同的值作為毫秒數解讀則落在 1970 年。 顯示時間戳需要時區資訊。UTC 使用後綴 `Z` 表示；其他偏移量使用 `±HH:MM`（例如中國標準時間為 `+08:00`，美國東部標準時間為 `-05:00`）。ISO 8601 允許多種可選分隔符，而 RFC 3339 是更嚴格的規範，固定了分隔符格式，這就是為什麼 API 規格通常要求使用帶有明確偏移量的 RFC 3339。使用 32 位有號整數儲存紀元秒數的舊系統將在最大正值 2147483647 時溢位，解碼為 2038-01-19T03:14:07Z（Y2038 問題）；64 位儲存將邊界推至遠超人類相關的範圍。
- Unix 紀元固定為 1970-01-01T00:00:00Z，POSIX 時間忽略閏秒，因此每一天都被視為恰好 86,400 秒。
- JavaScript Date.now() 返回毫秒數；`Math.floor(Date.now() / 1000)` 轉換為秒級時間戳。
- Y2038 邊界：有號 32 位時間戳在 2147483647 = 2038-01-19T03:14:07Z 時溢位；64 位儲存可避免此問題。
- ISO 8601 與 RFC 3339：RFC 3339 是更嚴格的 ISO 8601 規範，要求明確的偏移量（`Z` 或 `±HH:MM`），適用於 API 和日誌。
- ECMAScript Date 限制在紀元前後 ±100,000,000 天（約 ±273,785 年），因此 `new Date(8.64e15)` 和 `new Date(-8.64e15)` 是絕對邊界。
- JWT 的 `exp`、`iat` 和 `nbf` 聲明、`Cache-Control: max-age` 以及 Cookie 的 `Expires` 都使用 Unix 秒數（RFC 7519、RFC 7234），因此可以直接與 `Math.floor(Date.now()/1000)` 進行加減運算。
- 時區影響顯示的日期時間，但不影響時間戳值本身；同一紀元秒在 UTC+8 和 UTC-5 中會顯示為不同的時鐘時間。
範例
將 10 位 Unix 時間戳轉換為可讀日期
輸入： 1781526600
UTC: 2026-06-15 12:30:00
北京 (UTC+8)： 2026-06-15 20:30:00
ISO 8601: 2026-06-15T12:30:00Z
POSIX: IEEE 1003.1 將 Unix 時間定義為自 1970-01-01 00:00:00 UTC（Epoch）以來的秒數
ISO: ISO 8601 定義 YYYY-MM-DDThh:mm:ssZ 格式以明確表示日期時間將日期反向轉回時間戳
輸入： 2026-01-01 00:00:00 (UTC)
秒（10 位）： 1767225600
毫秒（13 位）： 1767225600000
Unix 指令： date -d @1767225600
備註： JavaScript Date.getTime() 回傳毫秒；Python time.time() 回傳秒（浮點數）
POSIX: time_t 型別傳統上是 32 位元或 64 位元有號整數辨別秒與毫秒
1781526600 -> 10 位，秒 -> 2026-06-15 12:30:00 UTC
1781526600000 -> 13 位，毫秒 -> 2026-06-15 12:30:00.000 UTC
常見錯誤：將 13 位數值當作秒解讀會得到約西元 74,000 年
快速判斷：10-11 位 = 秒（1970-2286），13 位 = 毫秒（JavaScript 預設）解碼 JWT exp 宣告
JWT payload: { "exp": 1798617600 }
解碼後： 2027-01-01 00:00:00 UTC
目前時間： 1781526600
剩餘有效： 17,091,000 秒（約 198 天）
RFC: RFC 7519 第 2 節將 NumericDate 定義為自 Epoch 以來的秒數Y2038 邊界檢查
32 位元有號最大時間戳： 2147483647
解碼後： 2038-01-19 03:14:07 UTC
再過一秒： 2147483648 -> 在舊式 32 位元系統上溢位
解法： 使用 64 位元 time_t（現代 Linux/macOS 預設）或以 ISO 8601 字串儲存
POSIX: 32 位元 time_t 系統將於 2038-01-19 之後發生環繞常見問題
什麼是 Unix 時間戳？
從 1970-01-01 00:00:00 UTC（即「Unix 紀元」）算起經過的秒數。JavaScript 與許多 API 改用同一紀元起算的毫秒數（Unix 時間戳 × 1000）。本頁兩種格式都接受，並會以本地時間和 UTC 顯示對應的日期。
秒、毫秒、微秒、奈秒有什麼差別？
不同系統使用不同精度。Unix `time()` 回傳秒；JavaScript 的 Date.now() 回傳毫秒；Java 的 Instant 支援奈秒。頁面會依位數自動判斷：10 位 = 秒（範圍涵蓋 2001-2286 年）、13 位 = 毫秒、16 位 = 微秒、19 位 = 奈秒。
為什麼 2038 年 1 月 19 日很重要？
這就是「2038 年問題」：32 位元有號的 Unix 時間戳會在 2038-01-19 03:14:07 UTC 時溢位，仍使用 32 位元 time_t 的系統會跳回 1901 年。現代 64 位元系統可撐數十億年無虞，但舊式嵌入式系統需要修正。
如何處理時區？
Unix 時間戳本質上就是 UTC。頁面會顯示你的本地時間和 UTC，並可額外選擇任一 IANA 時區（Asia/Shanghai、America/New_York、Europe/London）顯示。各時區的日光節約時間會自動套用。
為什麼某些情況下「YYYY-MM-DD」會被當成 UTC 解析？
ISO 8601 沒有時區資訊的日期是有歧義的。JavaScript 的 Date 建構式會把純日期字串視為 UTC、把日期時間字串視為本地時間，這是有名的「差一天」錯誤源頭。本頁會明確標示套用的時區。
換算是在本機完成的嗎？
是的。底層用的是 JavaScript Date 加上 Intl.DateTimeFormat，不會上傳任何時間戳。
可以產生未來的時間戳嗎？
可以。選一個未來日期，頁面就會回傳對應的時間戳。適合用來設定 JWT 的 exp 欄位、cron 工作的測試日期，或程式中的快取過期時間。