Unix 時間戳記（Unix timestamp）通常表示自 1970-01-01 00:00:00 UTC 起經過的秒數；程式與資料庫也常用毫秒、微秒或奈秒。單看一串整數不一定能確定單位；若把毫秒當秒、把當地時間當 UTC，日期就會差很多。本文以同一個時間點對照常見單位和 Windows、NTP、Excel 的其他時間基準。查核日期：2026-10-05。
Unix 時間戳記單位快速對照表
以 2024-01-01T00:00:00Z 為例，這是 Unix epoch 後的 1,704,067,200 秒。每一列代表同一個時間點，只是計數單位不同。
| 單位／常見欄位名稱 | 每秒刻度數 | 2024-01-01 00:00 UTC 範例 | 實務上常見位數（當代日期） |
|---|---|---|---|
| Unix 秒（s、seconds、epoch seconds） | 1 | 1704067200 |
約 10 位 |
| Unix 毫秒（ms、milliseconds、epoch ms） | 1,000 | 1704067200000 |
約 13 位 |
| Unix 微秒（µs、us、microseconds） | 1,000,000 | 1704067200000000 |
約 16 位 |
| Unix 奈秒（ns、nanoseconds） | 1,000,000,000 | 1704067200000000000 |
約 19 位 |
快速辨認只能當線索。 現代日期的秒、毫秒、微秒和奈秒常有上表位數，但遠古／遠期日期、負數、前置零、浮點表示或專有格式都會讓位數判斷失效。應先查欄位文件、變數名稱或 API 規格，不要只憑數字長度猜單位。
秒、毫秒、微秒和奈秒互轉方法表
| 換算方向 | 方法 | 範例 |
|---|---|---|
| 秒 → 毫秒 | 秒 × 1,000 | 1704067200 × 1000 = 1704067200000 ms |
| 毫秒 → 秒 | 毫秒 ÷ 1,000 | 1704067200000 ÷ 1000 = 1704067200 s |
| 秒 → 微秒 | 秒 × 1,000,000 | 1704067200 × 10⁶ = 1704067200000000 µs |
| 微秒 → 秒 | 微秒 ÷ 1,000,000 | 1704067200000000 ÷ 10⁶ = 1704067200 s |
| 秒 → 奈秒 | 秒 × 1,000,000,000 | 1704067200 × 10⁹ = 1704067200000000000 ns |
| 奈秒 → 秒 | 奈秒 ÷ 1,000,000,000 | 1704067200000000000 ÷ 10⁹ = 1704067200 s |
| 毫秒 → 微秒 | 毫秒 × 1,000 | 250 ms = 250000 µs |
| 微秒 → 奈秒 | 微秒 × 1,000 | 250 µs = 250000 ns |
時間戳記可能帶小數，例如 1704067200.125 秒等於 1704067200125 毫秒，也可表示為 UTC 的 2024-01-01T00:00:00.125Z。小數位表示的精度不代表系統時鐘或儲存設備真的有相同精度。
從時間戳記換成日期時間的步驟
- 確認單位：先辨認欄位是秒、毫秒、微秒、奈秒或其他計數單位。
- 換成秒：ms 除以 1,000；µs 除以 1,000,000；ns 除以 1,000,000,000。
- 從 UTC epoch 起算：把秒數加到
1970-01-01T00:00:00Z，得到對應 UTC 時間。 - 要顯示當地時間時再指定時區：用
Asia/Taipei等地區時區規則轉換，不要把 UTC 數值本身改成當地時間後重存。 - 檢查正負號及範圍：負 timestamp 可以表示 1970 年以前的時間；特定程式、ABI 和資料型別仍可能有可表示範圍限制。
例如 1704067200000 若欄位單位為毫秒，先除以 1,000 得 1704067200 秒，換成 UTC 是 2024-01-01 00:00:00Z；顯示在台北時區則是 2024-01-01 08:00:00 +08:00。若把同一數值誤當秒，會落在完全不同的年代。
常見 epoch 與日期序號不是同一套數值
| 格式／系統 | 起算點 | 計數單位和示例 | 使用時要留意 |
|---|---|---|---|
| Unix／POSIX timestamp | 1970-01-01 00:00:00 UTC |
常見為秒；2024 例為 1704067200 |
Unix 秒通常不計閏秒；負值可表示 epoch 以前時間 |
| Windows FILETIME | 1601-01-01 00:00:00 UTC |
64 位元數值，每單位 100 ns；2024 例為 133485408000000000 |
1 秒有 10,000,000 個 tick；檔案系統回報精度可能低於儲存單位 |
| NTP timestamp（era 0） | 1900-01-01 00:00:00 UTC |
64 位元格式由秒欄位及二進位小數欄位組成；Unix 2024 例的 NTP 秒欄位為 3913056000 |
NTP 的秒欄位約每 136 年回捲，須搭配 era 才能判斷完整日期；正式封包也含小數欄位 |
| Excel 1900 日期系統 | 序號以 1900 日期系統計日，日期儲存格可含一天的小數部分 | 2024-01-01 為 45292；中午為 45292.5 |
Excel 日期序號不是 Unix timestamp，也沒有內建時區 |
| Excel 1904 日期系統 | 1904 日期系統起算 | 2024-01-01 為 43830 |
同一天與 1900 系統相差 1,462 日；跨活頁簿要確認日期系統 |
FILETIME 的一個單位是 100 奈秒，因此可用 FILETIME = (Unix 秒 + 11,644,473,600) × 10,000,000 換算整秒時間。若 Unix 數值帶小數秒，先以 100 ns 為單位換成整數 tick，並留意目標程式採用的四捨五入方式。
NTP 是固定小數格式，不是把 Unix 秒乘上十億。RFC 5905 的 64 位元 NTP timestamp 分為 32 位元整秒與 32 位元二進位小數；若手上只有封包欄位，不能把整段 64 位數直接當十進位秒或 Unix nanoseconds 解讀。NTP era 0 大約於 2036 年回捲，需結合已知日期範圍判讀。
Excel 的日期序號只代表日期／一天中的時間比例；它沒有 UTC offset 或地區時區。將資料匯入 Excel 時，先確認原值是 UTC、當地時間還是單純日期，再套用時區轉換，避免把 Excel 日期序號誤當絕對時間點。Microsoft 說明 1900 與 1904 日期系統相差 1,462 天。
負 timestamp、閏秒與 2038 年界線
| 數值／時間 | 意義 | 注意事項 |
|---|---|---|
|
Unix epoch，即 1970-01-01T00:00:00Z |
不代表各地當地時間都是 1 月 1 日午夜 |
-1 秒 |
1969-12-31T23:59:59Z |
RFC 9636 定義負 Unix 時間可表示 epoch 以前的時間；個別 API 可能有範圍限制 |
2,147,483,647 秒 |
有號 32 位元最大正值，對應 2038-01-19T03:14:07Z |
對仍使用有號 32 位元 time_t 的程式是上限，不是所有 Unix 系統的共同失效日 |
2,147,483,648 秒 |
下一秒，2038-01-19T03:14:08Z |
32 位元 time_t 無法表示；應使用更寬的時間型別和完整測試 |
POSIX／Unix timestamp 的秒計數通常忽略閏秒，因此它是跨系統的實用時間軸表示，不等於從 UTC epoch 起把每個物理 SI 秒（包含每次閏秒）直接累加的結果。需要高精度計時、科學時間或明確追蹤閏秒時，請確認來源使用 UTC、TAI、GPS time、POSIX time 或其他時標；不能把它們只靠加減固定時差就視為完全相同。
傳輸與程式資料精度檢查
| 檢查項目 | 常見陷阱 | 建議做法 |
|---|---|---|
| API 欄位單位 | 文件寫 timestamp，沒說秒或毫秒 |
欄位名、schema 和範例明確標註單位，避免只傳裸數字 |
| JSON 大整數 | Unix 奈秒約 19 位，超過許多 IEEE 754 binary64 JSON parser 可保證精確表示的整數範圍 | 跨語言傳奈秒或 64 位整數時，以十進位字串、明確拆欄或確認雙方支援精確整數 |
| 小數秒 | 浮點運算可能出現二進位近似誤差 | 金融／排序／精密日誌可拆為整秒＋奈秒欄位，或以整數儲存最小單位 |
| 時區 | Unix timestamp 是一個時間點，並非「目前時區的牆上時間」 | 顯示前用明確時區轉換；未來排程還要保存 IANA 地區時區名稱 |
| 精度和解析度 | 欄位有 ns 不等於時鐘真的準到 ns | 分開記錄欄位單位、時鐘解析度、來源誤差和同步方式 |
| 範圍與溢位 | 32 位元時間、毫秒乘法或窄整數會溢位 | 檢查輸入範圍及中間運算型別；不要只確認最後顯示正常 |
常見誤讀
- 把毫秒值當秒值：秒通常 10 位、毫秒通常 13 位，但仍須查欄位定義。
- 把時間戳記直接當台北當地時間：timestamp 對應一個時間點；顯示時才選
Asia/Taipei等時區。 - 把 Unix epoch、NTP epoch 和 FILETIME 當同一個起點：三者起算日和單位都不同。
- 把 Excel 日期序號當 Unix 秒：Excel serial 以日為單位，還有 1900／1904 兩套系統。
- 認為奈秒欄位代表奈秒級準確度：資料表示單位、計時器解析度與實際準確度是不同概念。
- 忽略 32 位元時間範圍：特定舊程式會在 2038 邊界前後溢位，現代 64 位元系統通常使用更寬型別，但程式 ABI、檔案格式或外部 API 仍可能有限制。
RFC 3339 時間戳記格式、UTC offset 和 IANA 時區的區別，另見日期時間格式、UTC 時差與時區怎麼判讀。本文側重整數時間戳記和不同 epoch 的換算；跨系統存檔應同時保留清楚的欄位名稱、精度、時區或時間尺度定義。
官方規格與參考資料
- RFC 9636：Time Zone Information Format (TZif)：定義 POSIX epoch 為 1970-01-01 00:00 UTC、Unix time 秒計數不包括閏秒，並說明負 timestamp 及 32／64 位元時間範圍。
- RFC 5905：Network Time Protocol Version 4：定義 NTP epoch、64 位元時間戳記組成和 NTP era 0 的回捲。
- Microsoft Learn：FILETIME 結構：Windows FILETIME 為自 1601-01-01 UTC 起算的 100 ns 間隔數。
- Microsoft Support：Excel 日期系統：說明 1900／1904 系統的基準日和 1,462 天差異。
- RFC 8259：JSON：說明常見 binary64 JSON 實作能互通精確表示的整數範圍及大型數字精度風險。
- Linux man-pages：time(2)：說明 32 位元
time_t在 2038 年界線的溢位情況；其他平台及型別請查各自文件。
資料記錄