0
1970-01-01T00:00:00Z
946684800
2000-01-01T00:00:00Z
2147483647
2038-01-19T03:14:07Z — max for 32-bit signed int
9223372036854775807
~292 billion years — no practical overflow
86400000
60 × 60 × 24 × 1000
31536000
365 × 24 × 60 × 60 (non-leap)
2024-01-15T12:30:00Z
YYYY-MM-DDTHH:MM:SSZ — widely recommended
2024-01-15T07:30:00-05:00
YYYY-MM-DDTHH:MM:SS±HH:MM
Mon, 15 Jan 2024 12:30:00 +0000
Used in email headers and HTTP headers
2024-01-15T12:30:00.000Z
Subset of ISO 8601 with milliseconds
Mon, 15 Jan 2024 12:30:00 GMT
Used in HTTP headers (Last-Modified, Date)
01/15/2024
Ambiguous — avoid in APIs
15/01/2024
Ambiguous — avoid in APIs
2024-01-15
SQL DATE type, BigQuery, Redshift
20240115123000
Lexicographically sortable
Date.now()
Returns milliseconds since epoch
Math.floor(Date.now() / 1000)
Returns whole seconds
new Date(ts * 1000).toISOString()
Multiply by 1000 if ts is in seconds
Math.floor(new Date('2024-01-15T12:30:00Z').getTime() / 1000)import time; time.time()
Returns float with sub-second precision
from datetime import datetime, timezone datetime.fromtimestamp(ts, tz=timezone.utc)
Always pass tz=timezone.utc to avoid local timezone
from datetime import datetime, timezone
datetime.fromisoformat('2024-01-15T12:30:00+00:00').timestamp()SELECT EXTRACT(EPOCH FROM NOW())::BIGINT;
Returns whole seconds
SELECT to_timestamp(1705319400);
SELECT UNIX_TIMESTAMP();
SELECT FROM_UNIXTIME(1705319400);
time.Now().UnixNano()
Nanoseconds precision
time.Now().Unix()
SystemTime::now().duration_since(UNIX_EPOCH).unwrap().as_secs()
time()
Returns seconds; microtime(true) for float
date +%s
GNU/BSD date; on macOS same command works
+00:00
Coordinated Universal Time — no DST
-05:00 / -04:00
EST in winter, EDT in summer (DST)
-06:00 / -05:00
-07:00 / -06:00
-08:00 / -07:00
+00:00 / +01:00
BST (British Summer Time) in summer
+01:00 / +02:00
Germany, France, Italy, Poland, etc.
+05:30
No DST — half-hour offset
+08:00
No DST — entire country one timezone
+09:00
No DST
+10:00 / +11:00
DST in southern hemisphere summer (Oct–Apr)
+12:00 / +13:00
| 單位 | 位數 | 範例 | 大致範圍 |
|---|---|---|---|
| Seconds (s) | 10 | 1705319400 | 1970 – 2286 |
| Milliseconds (ms) | 13 | 1705319400000 | 1970 – 2286 (×1000) |
| Microseconds (μs) | 16 | 1705319400000000 | Sub-second precision |
| Nanoseconds (ns) | 19 | 1705319400000000000 | Used by Go, Rust, Linux kernel |
Unix 時間戳一律是 UTC。它們不包含時區資訊。這其實是一個優點——它提供了一個通用的參考點。
混淆通常發生在將時間戳轉換為人類可讀的日期時：
const ts = 1700000000;
const date = new Date(ts * 1000);
date.toUTCString(); // "Tue, 14 Nov 2023 22:13:20 GMT"
date.toLocaleString(); // Depends on user's local time zone
date.toISOString(); // "2023-11-14T22:13:20.000Z"
最佳實踐：以 UTC 儲存和傳輸時間戳。只在展示層將其轉換為本地時間，越靠近使用者越好。
-- Current timestamp
SELECT EXTRACT(EPOCH FROM NOW());
-- Timestamp to date
SELECT TO_TIMESTAMP(1700000000);
-- Date to timestamp
SELECT EXTRACT(EPOCH FROM '2023-11-14'::timestamp);
如果日期顯示為 1970 年 1 月，表示你可能在預期毫秒的地方傳入了秒（或反過來）。務必確認 API 預期的精度。
將時間戳儲存為浮點數時，超過毫秒可能會失去精度。對於需要微秒或奈秒精度的場景，使用整數並搭配適當的倍數。
Unix 時間戳不考慮閏秒。Unix 的一天永遠是剛好 86,400 秒，即使實際的 UTC 天偶爾有 86,401 秒。對大多數應用來說這不影響。對於科學或衛星應用，請改用 TAI（國際原子時）。
將日期存為時間戳（整數或原生 datetime 類型），以便高效排序、比較和運算。格式化字串更難正確查詢和排序。大多數資料庫都有原生 datetime 類型能妥善處理。將字串格式化保留給展示和 API 回應。
Unix時間戳（也稱為紀元時間）是自1970年1月1日00:00:00 UTC以來經過的秒數（不計閏秒）。它是一個單一整數，可以明確識別時區獨立的任何時刻。
傳統Unix時間戳計算完整的秒數。現代語言和API（JavaScript Date.now()、Java System.currentTimeMillis()）使用毫秒（大1000倍）來實現亞秒精度。互操作時，始終檢查量級：10位數字是秒，13位數字是毫秒。
32位有符號整數最多可以表示到2,147,483,647，對應2038年1月19日03:14:07 UTC。在那之後，32位系統將溢出為負值。64位系統可以安全地表示超過2920億年的日期。
JavaScript: new Date(ts * 1000).toISOString()。Python: datetime.fromtimestamp(ts, tz=timezone.utc).isoformat()。SQL（PostgreSQL）: to_timestamp(ts)。UTC的ISO 8601格式為YYYY-MM-DDTHH:MM:SSZ，例如2024-01-15T12:30:00Z。