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(); // 取决于用户的本地时区
date.toISOString(); // "2023-11-14T22:13:20.000Z"
最佳实践：以 UTC 存储和传输时间戳。仅在显示层、尽可能靠近用户的位置转换为本地时间。
-- 当前时间戳
SELECT EXTRACT(EPOCH FROM NOW());
-- 时间戳转日期
SELECT TO_TIMESTAMP(1700000000);
-- 日期转时间戳
SELECT EXTRACT(EPOCH FROM '2023-11-14'::timestamp);
如果日期显示为 1970 年 1 月，你可能在期望毫秒的地方传入了秒（或反之）。始终检查 API 期望的精度。
将时间戳存储为浮点数时，可能会丢失毫秒以上的精度。对于微秒或纳秒精度，请使用适当乘数的整数。
Unix 时间戳不考虑闰秒。Unix 日始终恰好是 86,400 秒，即使实际的 UTC 日偶尔有 86,401 秒。对于大多数应用来说，这无关紧要。对于科学或卫星应用，请使用 TAI（国际原子时）代替。
将日期存储为时间戳（整数或原生日期时间类型）以便高效排序、比较和运算。格式化字符串更难以正确查询和排序。大多数数据库具有处理此问题的原生日期时间类型。将字符串格式化保留给显示和 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。