Unix 타임스탬프를 날짜로 변환
Unix 타임스탬프를 읽기 쉬운 날짜와 시간으로 변환하거나, 어떤 날짜든 다시 Unix 타임스탬프로 변환합니다. 초와 밀리초를 지원합니다.
Unix 타임스탬프란?
Unix 타임스탬프(Unix time 또는 POSIX time이라고도 함)는 Unix 기원점(Unix epoch)인 1970-01-01 00:00:00 UTC 이후 경과한 초의 개수입니다. 시간의 한 순간을 단일 정수로 나타낼 수 있어 저장, 비교, 계산이 간단하므로 컴퓨팅에서 널리 사용되는 표준입니다.
JavaScript는 내부적으로 밀리초 단위로 작동하므로 Date.now()는 Unix 타임스탐프에 1000을 곱한 값을 반환합니다. 많은 API, 데이터베이스, 백엔드 시스템은 초 단위를 사용합니다. 이 도구는 두 형식을 모두 받아들이며, 입력하는 숫자의 크기에 따라 초인지 밀리초인지 자동으로 감지합니다.
주요 Unix 타임스탬프
| 타임스탬프 | 날짜 (UTC) | 설명 |
|---|---|---|
0 | 1970-01-01 00:00:00 | Unix 기원점 |
1,000,000,000 | 2001-09-09 01:46:40 | 10억 초 |
2,000,000,000 | 2033-05-18 03:33:20 | 20억 초 |
2,147,483,647 | 2038-01-19 03:14:07 | 2038년 문제 (32비트 최댓값) |
왜 1970년일까?
Unix 기원점인 1970년 1월 1일은 관례와 실제적인 제약이 결합되어 선택되었습니다. Unix는 1960년대 후반과 1970년대 초반 Bell Labs에서 개발되었습니다. 개발자들은 시간 표현을 위해 최근의 깔끔한 시작일이 필요했습니다. 1970년 1월 1일은 충분히 최근이어서 실용적이었고, 특별한 기술적 의미는 없었습니다. 단지 편리한 기준점이었을 뿐입니다.
다른 시스템에서는 다른 기원점을 사용합니다. Windows FILETIME의 기원점은 1601년 1월 1일이고, GPS 시간은 1980년 1월 6일에 시작되며, NTP 기원점은 1900년 1월 1일입니다. 시스템 간에 변환할 때는 각 시스템의 기원점을 아는 것이 필수적입니다.
초 vs 밀리초
원래의 Unix 타임스탬프는 초 단위입니다. 대부분의 서버 측 언어와 시스템(Unix 셸, Python의 time.time(), PHP의 time(), 대부분의 데이터베이스)은 초를 사용합니다. JavaScript의 Date.now()와 new Date().getTime()은 밀리초를 반환합니다. 이러한 불일치는 JavaScript 프론트엔드가 백엔드 API와 통신할 때 버그의 일반적인 원인입니다.
현재 초 단위 Unix 타임스탬프는 10자리 숫자입니다(2023년 기준 약 1,700,000,000). 밀리초 타임스탬프는 13자리 숫자입니다. 이 계산기는 입력한 숫자의 자릿수를 기반으로 어느 형식인지 감지하고 그에 따라 변환합니다.
2038년 문제
Unix 타임스탬프를 부호 있는 32비트 정수로 저장하는 시스템은 기원점 이후 2,147,483,647초까지만 나타낼 수 있습니다. 이는 2038년 1월 19일 UTC 03:14:07입니다. 그 이후로는 32비트 부호 있는 정수가 오버플로우되어 1901년의 날짜를 나타내는 큰 음수가 됩니다.
이를 "Y2K38" 문제 또는 Unix 밀레니엄 버그라고도 부릅니다. 현대의 64비트 시스템은 영향을 받지 않습니다. 64비트 부호 있는 정수는 약 2,920억 년 동안의 타임스탬프를 나타낼 수 있기 때문입니다. 하지만 임베디드 시스템, 레거시 데이터베이스, 오래된 32비트 소프트웨어는 여전히 취약할 수 있습니다. 통신, 금융, 산업용 제어 시스템을 포함한 많은 산업에서 이를 해결하기 위한 마이그레이션 노력이 진행 중입니다.
현재 Unix 타임스탬프를 얻는 방법
| 언어 / 환경 | 명령어 |
|---|---|
| JavaScript | Math.floor(Date.now() / 1000) |
| Python | import time; int(time.time()) |
| PHP | time() |
| Bash | date +%s |
| SQL (PostgreSQL) | EXTRACT(EPOCH FROM NOW())::int |
| SQL (MySQL) | UNIX_TIMESTAMP() |
| Go | time.Now().Unix() |
| Rust | SystemTime::now().duration_since(UNIX_EPOCH).unwrap().as_secs() |
실제 사용 사례
API 개발: REST API는 일반적으로 created_at, updated_at, 토큰 만료 필드에 Unix 타임스탬프를 사용합니다. 타임스탬프는 시간대에 관계없고 명확합니다. 형식화된 날짜 문자열과 달리 로캘과 형식 규칙에 의존하지 않습니다.
토큰 만료: JWT(JSON Web Token)는 exp(만료), iat(발급) 클레임에 Unix 타임스탬프를 사용합니다. 현재 타임스탬프가 exp 값을 초과하면 토큰이 만료됩니다. 만료 시간을 계산하려면(예: "이 토큰은 24시간 후에 만료되어야 함") 현재 타임스탬프에 86,400초를 더합니다.
캐시 TTL: 캐시 만료는 보통 Unix 타임스탬프 또는 현재부터의 초 단위로 설정됩니다. 캐시 문제를 디버깅할 때는 저장된 만료 타임스탬프를 사람이 읽을 수 있는 날짜로 변환해야 합니다.
로그 분석: 서버 로그는 대개 Unix 타임스탐프를 포함합니다. 이를 읽을 수 있는 날짜로 변환하는 것은 로그 항목을 실제 이벤트와 연관 짓기 위한 첫 단계입니다.
데이터베이스 저장: 타임스탐프를 형식화된 문자열이 아닌 정수로 저장하면 시간대 변환 버그를 피하고 정렬, 범위 쿼리, 계산을 간단히 할 수 있습니다. "지난 7일 동안의 모든 레코드"를 조회하는 쿼리는 WHERE created_at > (NOW_UNIX - 604800)이 됩니다.
