RunToolz iconRunToolz
Welcome to RunToolz!
時間戳程式設計資料庫

什麼是 Unix 時間戳以及你為什麼應該關心?

資料庫中的那個巨大數字不是隨機的,它是 Unix 時間戳。了解時間戳的工作原理、與日期的相互轉換方法,以及在程式設計和資料庫中的實際應用。

RunToolz Team2026年1月12日5 min read

你在除錯 API 回應。有一個叫 created_at 的欄位,值為 1704067200。那是哪一天?

那是一個 Unix 時間戳。這是自 1970 年 1 月 1 日以來的秒數。一旦你理解它,你會到處看到它。

為什麼是 1970 年?

Unix 在 1960 年代後期被開發。設計師需要一個時間計算的起點。1970 年 1 月 1 日足夠近以實用,足夠早以涵蓋大多數計算歷史。

那個時刻——1970 年 1 月 1 日午夜 UTC——被稱為 Unix 紀元。

想親自試試嗎?轉換時間戳

為什麼是秒而不是日期?

日期很複雜。時區、夏令時間、閏年、不同的月份長度。「2024 年 3 月 15 日下午 3 點 EST」需要大量解析。

時間戳只是一個數字。1710522000。易於儲存,易於比較,易於進行數學運算。

想知道哪個事件先發生?比較兩個數字。想知道某事花了多長時間?減去時間戳。想添加 24 小時?加 86400。

時區優勢

這是聰明的部分:時間戳總是 UTC。

當東京的某人和紐約的某人都記錄同一時刻時,他們得到相同的時間戳。顯示可能不同——一個看到上午 9 點,另一個看到晚上 7 點——但底層數字是相同的。

這使分散式系統成為可能。資料庫、API、日誌檔案——都使用相同的參考點,無論伺服器在哪裡。

毫秒 vs 秒

JavaScript 使用自紀元以來的毫秒。大多數其他語言使用秒。

1704067200(秒)= 2024 年 1 月 1 日,00:00:00 UTC 1704067200000(毫秒)= 同一時刻

如果時間戳看起來太大,它可能是毫秒。除以 1000。

快速讀取時間戳

幾個參考點來校準你的心算:

  • 1000000000(10 億)= 2001 年 9 月 9 日
  • 1600000000 = 2020 年 9 月
  • 1700000000 = 2023 年 11 月
  • 1800000000 = 2027 年 1 月

當前時間戳在 17 億範圍內。如果你看到以 17 開頭的東西,它可能是最近的時間戳。

常見操作

當前時間戳:

Math.floor(Date.now() / 1000)  // JavaScript
import time; int(time.time())  # Python

時間戳轉日期:

new Date(1704067200 * 1000)  // JavaScript 需要毫秒

日期轉時間戳:

Math.floor(new Date('2024-01-01').getTime() / 1000)

2038 年問題

Unix 時間戳最初儲存為 32 位元有符號整數。最大值?2,147,483,647。

那是 2038 年 1 月 19 日,03:14:07 UTC。

在那個時刻之後,32 位元系統將溢位。這是時間戳的千禧蟲問題。

大多數現代系統現在使用 64 位元整數,數十億年內不會溢位。但舊系統存在。如果你在處理舊程式碼,值得檢查。

當時間戳變得奇怪

負時間戳。 1970 年之前的日期是負數。-86400 是 1969 年 12 月 31 日。

閏秒。 UTC 偶爾會添加一秒以與地球自轉保持同步。大多數系統忽略這個。偶爾會引起混亂。

時鐘漂移。 伺服器的時鐘可能不一致。來自不同機器的兩個時間戳如果時鐘未同步可能無法直接比較。


一旦你開始尋找,時間戳無處不在。API 回應、資料庫記錄、日誌檔案、cookie。理解它們使除錯更快,與時間相關的程式碼不那麼神秘。