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 일은 실제 UTC 일이 간혹 86,401초를 가져도 항상 정확히 86,400초입니다. 대부분의 애플리케이션에서 이것은 무관합니다. 과학이나 위성 애플리케이션에는 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입니다.