如何將紀元時間轉換為日期？

先辨別數值是秒（10 位）還是毫秒（13 位），再用你所用語言的日期 API 轉換——JavaScript 用 new Date(seconds * 1000)，Python 用 datetime.fromtimestamp(seconds, tz=timezone.utc)，或貼到上方的轉換器。

為什麼我的紀元時間戳轉換後是 1970 年？

你把秒值傳給了期望毫秒的函式，多數情況是 JavaScript 的 new Date()。先把 10 位的秒值乘以 1000。

紀元時間該轉換為 UTC 還是本地時間？

日誌、API 與跨伺服器比較用 UTC，只在顯示時才轉換為使用者的本地時區。紀元值本身與時區無關。

在 JavaScript 中如何從 Unix 時間戳得到日期？

new Date(seconds * 1000) 會回傳一個 Date 物件，可用 toISOString()、toUTCString() 或 Intl.DateTimeFormat 格式化。需要相乘是因為 JavaScript 的 Date 期望毫秒而非秒。

在 Python 中如何從 Unix 時間戳得到日期？

要得到帶時區的 UTC datetime，用 datetime.fromtimestamp(seconds, tz=timezone.utc)。本地時間則省略 tz 參數，需要 ISO 8601 字串則追加 .isoformat()。

同一個紀元值在不同時區會得到不同日期嗎？

瞬間在任何地方都相同，但你顯示的掛鐘日期取決於時區——甚至可能落在不同的日曆日。1700000000 在紐約是 11 月 14 日，在東京是 11 月 15 日。

如何把時間戳轉換為日期？

每種現代語言都有一行內建函式。最難的部分是辨別時間戳是秒（10 位）還是毫秒（13 位）——只要單位對了，轉換本身從不出錯。

Epoch to Date

如何將紀元時間轉換為可讀日期

將紀元時間轉換為日期只需兩步——把數字解碼為 UTC 上的一個瞬間，再把該瞬間格式化為你需要的時區。本指南說明心智模型、如何區分秒與毫秒、UTC 還是本地的取捨，並帶你前往分語言的範例與即時轉換工具。

紀元到日期只需兩步

把紀元時間戳轉換為可讀日期，永遠是同樣的兩步：把數字解碼為 UTC 上的一個瞬間，再把該瞬間格式化為你想顯示的時區。數字本身不帶時區——它只是一個瞬間——所以同一個值會因你格式化所用的時區不同，而顯示為不同的掛鐘時間（有時是不同的日曆日）。下表把一個時間戳呈現在多個時區中；本指南其餘部分說明單位、時區選擇與程式碼。

時區	1700000000 的本地日期與時間
UTC（規範瞬間）	2023-11-14 22:13:20 · ISO 2023-11-14T22:13:20Z
America/New_York	2023-11-14 17:13:20 (EST)
Asia/Tokyo	2023-11-15 07:13:20 (JST)
Australia/Sydney	2023-11-15 09:13:20 (AEDT)

開啟紀元→日期轉換器

什麼是紀元時間？

紀元時間（也稱 Unix 時間或 POSIX 時間）是自 1970 年 1 月 1 日 00:00:00 UTC 起經過的秒數。它是運算領域表示瞬間的通用標準。每種程式語言與作業系統都原生支援，使其成為在系統間儲存與交換時間戳最可靠的格式。

The Open Group — Seconds Since the Epoch (POSIX)

第 1 步——辨別秒還是毫秒

轉換前先確定單位。幾乎總能從位數讀出，而讀錯單位是日期出錯最常見的原因。

10 位（例如 1700000000）→ 自 Unix 紀元起的秒
13 位（例如 1700000000000）→ 自 Unix 紀元起的毫秒
16 位 → 微秒；19 位 → 奈秒
拿不準時，檢查解碼出的年份是否合理——落在 1970 年或遙遠未來說明單位讀錯了
上方的轉換器會自動偵測單位

Unix 時間戳格式——秒、毫秒、微秒、奈秒詳解

第 2 步——依 UTC 解碼，再選擇時區

Unix 時間戳會解碼為精確的一個瞬間。把該瞬間顯示為 UTC 還是本地時區，是顯示層面的決定，而非數字的屬性。面向機器的一切——日誌、API、資料庫儲存、跨伺服器比較——都選 UTC，只在向人顯示日期的那一刻才轉換為使用者的 IANA 時區。始終用 IANA 名稱（America/New_York）標識時區，絕不用裸偏移量，這樣日光節約時間才會自動套用。

面向機器（日誌、API、儲存）→ 顯示為 UTC，帶 Z 的 ISO 8601
面向使用者（截止時間、UI 中的時間戳）→ 轉換為使用者的 IANA 時區
切勿在不帶時區的情況下儲存本地時間——儲存 UTC 加 IANA 時區名稱

IANA 時區資料庫（每個執行階段都使用的規則）

用程式碼轉換

每種現代語言都有一行內建函式替你完成兩步。模式始終相同：以函式期望的單位傳入值，並請求 UTC 或某個特定時區。下面給出 JavaScript 等範例；配套範例完整涵蓋 JavaScript、Python、PHP、Java、C#、Go、SQL、Excel 與 Google Sheets。

JavaScript：new Date(1700000000 * 1000).toISOString() → "2023-11-14T22:13:20.000Z"
Python：datetime.fromtimestamp(1700000000, tz=timezone.utc).isoformat()
Shell：date -u -d @1700000000 (GNU) / date -u -r 1700000000 (BSD, macOS)
SQL：TO_TIMESTAMP(1700000000) (Postgres), FROM_UNIXTIME(1700000000) (MySQL)
規則：在期望秒的地方就傳秒——只有 JavaScript 的 Date 需要 × 1000

轉換紀元時間時的常見錯誤

轉換 Unix 時間戳時最常見的錯誤：

在 JavaScript 中忘記把秒乘以 1000——new Date(1700000000) 得到的是 1970 年而非 2023 年
在伺服器端語言中把 JavaScript 的毫秒直接當作秒使用（1000 倍誤差）
不指定時區，依賴各環境各異的伺服器本地時區
把時間戳存為字串而非整數，導致數值比較與運算出錯
在 Python 中使用已棄用的 datetime.utcfromtimestamp()——應改為給 fromtimestamp() 傳入 tz=timezone.utc

10 個常見的 Unix 時間戳錯誤及修復方法

FAQ

如何將紀元時間轉換為日期？: 先辨別數值是秒（10 位）還是毫秒（13 位），再用你所用語言的日期 API 轉換——JavaScript 用 new Date(seconds * 1000)，Python 用 datetime.fromtimestamp(seconds, tz=timezone.utc)，或貼到上方的轉換器。
為什麼我的紀元時間戳轉換後是 1970 年？: 你把秒值傳給了期望毫秒的函式，多數情況是 JavaScript 的 new Date()。先把 10 位的秒值乘以 1000。
紀元時間該轉換為 UTC 還是本地時間？: 日誌、API 與跨伺服器比較用 UTC，只在顯示時才轉換為使用者的本地時區。紀元值本身與時區無關。
在 JavaScript 中如何從 Unix 時間戳得到日期？: new Date(seconds * 1000) 會回傳一個 Date 物件，可用 toISOString()、toUTCString() 或 Intl.DateTimeFormat 格式化。需要相乘是因為 JavaScript 的 Date 期望毫秒而非秒。
在 Python 中如何從 Unix 時間戳得到日期？: 要得到帶時區的 UTC datetime，用 datetime.fromtimestamp(seconds, tz=timezone.utc)。本地時間則省略 tz 參數，需要 ISO 8601 字串則追加 .isoformat()。
同一個紀元值在不同時區會得到不同日期嗎？: 瞬間在任何地方都相同，但你顯示的掛鐘日期取決於時區——甚至可能落在不同的日曆日。1700000000 在紐約是 11 月 14 日，在東京是 11 月 15 日。
如何把時間戳轉換為日期？: 每種現代語言都有一行內建函式。最難的部分是辨別時間戳是秒（10 位）還是毫秒（13 位）——只要單位對了，轉換本身從不出錯。