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の1日は常に正確に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)。ISO 8601形式はUTCの場合YYYY-MM-DDTHH:MM:SSZ、例：2024-01-15T12:30:00Z。