解釋了Unix時間:秒，毫秒，時區和2038

Open almost any log file，database table or API response and you will find numbers like 1760000000。這是一個Unix時間:自1970年1月1日00:00:00 UTC以來的秒數，。計算機最常見的時間表現方式，瞭解它可以防止一系列涉及時區，夏令和日期解析的錯誤。

為什麼從1970年開始數秒？

早期的Unix開發人員需要一個簡單的，緊的時間表示。從一個固定的近期日期計算秒鐘，可以用一個整數，很容易比較和減去，避免了日曆的複雜性。1970年1月1日是Unix開發時一個方便的起點。

它們的優勢至今仍然存在:

• ** 獨立於時區.** 時間標識一個瞬間，而不是牆鍾讀數。在東京，柏林和聖保羅，
• 簡單的演算法. 兩個時間之間的區別是數秒的時間。增加了86,400個進步。
• **緊且可分類.**整數需要8位元組，並按時間順序排序。
• 明確. 03/04是3月4日或4月3日。

秒數與毫秒

最常見的時間錯誤是混合單位:

• 現在的Unix工具，大多數資料庫，JWT和許多API都使用秒,10個位數，例如1760000000。
• JavaScript 的 Date.now()，Java 的 System.currentTimeMillis() 和許多分析系統使用 毫秒：13 位數，如 1760000000000。
• 一些系統使用微秒 (16位數) 或奈米秒 (19位數)。

如果把毫秒解釋為秒鐘，。如果您在使用者介面中看到 "1970-01-21"，。一個時間轉換器可以透過長度檢測單位，這是一個快速的健康檢查。

將時間轉換為常用語言

簡介:

const nowSeconds = Math.floor(Date.now() / 1000);
const date = new Date(1760000000 * 1000);
date.toISOString(); // "2025-10-09T08:53:20.000Z"

它們是什麼？

import time, datetime
now = int(time.time())
dt = datetime.datetime.fromtimestamp(1760000000, tz=datetime.timezone.utc)

在Python中總是傳遞tz=;沒有它，fromtimestamp返回一個簡單的本地時間，很容易被誤解。

在此之前，

SELECT to_timestamp(1760000000);           -- timestamptz
SELECT extract(epoch FROM now())::bigint;  -- current Unix time

讓我們一起去吧。

t := time.Unix(1760000000, 0).UTC()
now := time.Now().Unix()

子

date +%s                    # current timestamp
date -u -d @1760000000      # GNU date
date -u -r 1760000000       # macOS/BSD date

時區:儲存UTC，顯示本地

時間沒有時區，它是絕對的瞬間。轉換到可讀資料時會出現問題:

• 沒有區間的日期傳輸. new Date("2026-03-29 02:30") 在執行程式碼的任何機器的本地時區中進行解釋。在UTC的伺服器和柏林的膝上型電腦上，
• **夏令時間的差距和重疊.**在夏令時間的區域，有些地方時間不存在 (時鐘向前跳動)，有些則發生兩次 (時鐘向後移動)。時間沒有這樣的模兩可。
• 如果您儲存"2026-11-01 01:30"沒有區間，您永遠無法確定它是什麼時刻。

基本規則:儲存和傳輸時間或ISO 8601字串，並明確偏移 (2026-10-11T09:30:00Z或+02:00)。只在顯示時轉換到使用者的本地區域。如果您需要按本地時間安排事情，請單獨儲存使用者的IANA時區名稱 (如Europe/Berlin)。

ISO 8601與Unix時間

像2026-10-11T09:30:00Z這樣的ISO 8601字串是人類可讀的，並且當它們包含Z或偏移時也是明確的。許多API更喜歡它們的可讀性。在Unix中，時間較小，比較快。兩者都很好，重要的是一致性，

秒

地球的旋轉有點不規則，所以官方UTC偶爾會插入秒。每一天的時間是86,400秒，在秒內，時間重複或被抹去。對於幾乎所有應用，。如果您需要高精度的定時，。國際計時機構已經決定到2035年逐步淘汰秒，

2038年的問題

許多舊系統將Unix時間儲存為一個簽名32位整數，其最大值為2,147,483,647。這與2038年1月19日的03:14:07 UTC相對應。一秒鐘後，該值溢位到 −2,147,483,648，表示1901年12月13日。

現代64位作業系統，語言和資料庫使用64位時間，。風險仍然存在於:

• 嵌入式裝置和具有長壽命的工業控制器。
• 有32位時間欄位的檔案格式和網路協議。
• 資料庫列被宣告為32位 INT 持有時代秒。MySQL 的 TIMESTAMP 型別有 2038 的限制；DATETIME 或 BIGINT 則沒有。

檢查長期儲存的資料，尤其是儲存未來日期的資料，

負時間

在1970年之前的日期有負時間。-86400 is 31 December 1969。大多數現代語言正確處理它們，但一些較舊的API和電子表格卻沒有，所以要明確測試歷史日期。

實用除錯檢查列表

1. 計算數字:秒數為10，毫秒為13。
2. 首先轉換為UTC，然後轉換為本地時間，以將單元錯誤與區域錯誤分開。
3. 在解析之前檢查日期字串是否包含 Z 或偏移。
4. 如果令牌或簽名失敗，則將伺服器和客戶端時鐘進行比較。請參閱[JWT如何工作] (http://blog/how-jwt-works) 瞭解為什麼exp和nbf是Unix秒。
5. 在安排重複工作時，請記住cron在伺服器的區域執行；[這些cron示例] (/blog/cron-expression-examples) 涵蓋詳情。

總結

一個Unix時間是自1970-01-01 UTC以來的秒數。它是簡單的，獨立於時區，易於計算。大多數錯誤來自混合秒和毫秒，解析沒有區的日期，。儲存UTC，在邊緣轉換，使用64位整數，