最後更新：2026-06-28

Unix 時間戳記（Epoch ⇄ 日期）

Unix 時間戳記（Unix timestamp）是一個整數，記錄自 1970-01-01 00:00:00 協調世界時（UTC）起所累積的秒數，亦稱為 epoch 時間或 POSIX 時間。由於這個數值與時區及曆法系統完全無關，它是電腦系統在儲存與傳遞時間點時最常見的通用格式。本計算機支援雙向轉換：數值 epoch 轉換為 UTC 可讀日期，以及日曆日期轉換回 epoch 數值。

Unix epoch 的起源

1970-01-01 00:00:00 UTC 這個起點，來自 1960 年代末貝爾實驗室開發早期 Unix 核心時的工程決定。當時開發團隊需要一個固定的時間參考點用於計算，具體日期的選擇並無深意，重要的是所有機器都採用相同的基準。這個慣例隨後納入 POSIX 標準，並延伸至今日幾乎所有作業系統與程式語言。

時間戳記 0 代表 epoch 本身。時間戳記 86,400 代表恰好一天後（60 秒 × 60 分鐘 × 24 小時）。負值代表 1970 年以前的時間點，在多數現代實作中同樣有效，可表示數千年前的日期。

秒與毫秒的區別

原始 Unix 標準以整秒計算。伺服器日誌、資料庫記錄、Shell 工具等多數 Unix 環境仍使用秒精度的時間戳記，在 2000 至 2030 年代的日期範圍內產生 10 位數的數值。

JavaScript 引入了毫秒精度的變體：Date.now() 與 Date.getTime() 回傳自 epoch 起的毫秒數，產生 13 位數的數值。許多 REST API、事件串流及 JavaScript 生態系的資料庫也沿用此慣例。

實用判斷原則：10 位數幾乎可確定是秒；13 位數幾乎可確定是毫秒。若要將毫秒轉為秒，除以 1,000 即可——選擇毫秒單位時，本計算機會自動完成此換算。

轉換原理

Epoch 轉日期。 給定以秒為單位的時間戳記 $t$，UTC 日期與時間的推算方式如下：

天數再依閏年規則對應至前置儒略曆（proleptic Gregorian）的日期。當日時間則以連續取餘數的方式分解為時、分、秒。

日期轉 Epoch。 給定 UTC 午夜的日曆日期，計算方式是統計自 1970-01-01 起的天數，再乘以 86,400。以 2024-01-01 為例，天數為 19,723（1970 至 1999 年共 10,957 天，加上 2000 至 2023 年共 8,766 天），對應的 epoch 為：

$19{,}723 \times 86{,}400 = 1{,}704{,}067{,}200 \text{ s}$

本計算機內部採用 Temporal API 處理閏年與曆法邊界情況，確保結果準確。

2038 年問題

許多舊系統以 32 位元有號整數儲存 Unix 時間戳記。32 位元有號整數的最大正值為 2,147,483,647，對應時間點為 2038-01-19 03:14:07 UTC。超過此刻後，計數器將溢位回最大負值（約 −21 億），使這些系統將日期誤判為 1901 年。

採用 64 位元整數的現代系統不受此問題影響。64 位元有號整數可表示往前或往後約 2,920 億年的時間範圍。2038 年問題是舊版軟體的遺留問題，並非 Unix epoch 概念本身的設計缺陷。多數主流作業系統、資料庫及程式語言已在 2020 年前完成 64 位元化。

常見注意事項

時區。 Unix 時間戳記始終以 1970-01-01 UTC 午夜為基準，本身不包含時區資訊。若要將本地時間轉換為 epoch，必須先將本地時間換算為 UTC。本計算機以 UTC 午夜作為日期輸入的標準解釋。

閏秒。 Unix epoch 不計入閏秒，假設每天恰好為 86,400 秒。因此，Unix 時間戳記與國際原子時（TAI）或精密授時機構所維護的秒計數並不完全相等。截至 2024 年，兩者累積偏差約 27 秒，在一般軟體應用中可忽略不計。

舊版程式碼的整數溢位。 即使主機作業系統已採用 64 位元時間，第三方程式庫、資料庫欄位型別或序列化格式可能仍以 32 位元整數儲存時間戳記。與外部系統交換資料時，若涉及 2038 年前後的時間精度需求，應確認儲存欄位的位元寬度。