API 로그를 보다가 created_at 값이 1709251200으로 찍혀 있다. 이게 2024년 3월 1일인지 2025년인지 숫자만 봐서는 감이 안 온다. 개발자라면 피할 수 없는 Unix 타임스탬프, 원리를 알면 단순하다.
Unix 타임스탬프의 구조
1970년 1월 1일 00:00:00 UTC(Epoch)부터 경과한 초(second) 수를 정수로 표현한 것이다. 시간대(timezone)와 무관하게 전 세계 어디서든 같은 숫자가 같은 순간을 가리킨다.
- 초 단위 (10자리)
- 예: 1709251200 → 2024-03-01 00:00:00 UTC
- 밀리초 단위 (13자리)
- 예: 1709251200000 → 같은 시점, JavaScript Date 객체에서 주로 사용
자릿수만 보면 초(10자리)인지 밀리초(13자리)인지 구분할 수 있다. API 문서에 명시되어 있지 않으면 자릿수로 판단하는 경우가 많다.
왜 숫자로 시간을 저장하나
- 시간대 독립: "2024-03-01 09:00"은 어느 나라 기준인지 모호하지만, 타임스탬프는 UTC 기준이라 혼동이 없다
- 비교/정렬 용이: 문자열 날짜 비교는 포맷에 따라 오류가 생기지만, 숫자는 대소 비교만 하면 된다
- 저장 공간 절약: 4~8바이트 정수 하나로 시간 정보를 담을 수 있다
- 언어/로케일 독립: "March 1, 2024"와 "2024년 3월 1일"은 같은 날이지만 포맷이 다르다. 타임스탬프는 포맷 이슈가 없다
변환 방법
코드로 변환할 수도 있지만, 디버깅 중에 빠르게 확인하고 싶을 때는 웹 도구가 편하다. 타임스탬프 변환기에서 숫자를 넣으면 로컬 시간, UTC, ISO 8601 세 가지 형식으로 동시에 변환된다. 반대로 날짜를 입력해서 타임스탬프 값을 뽑을 수도 있고, 현재 시각의 타임스탬프가 실시간으로 표시되니 테스트 데이터를 만들 때 바로 복사해서 쓸 수 있다.
2038년 문제란
32비트 정수로 표현할 수 있는 최대 타임스탬프는 2,147,483,647이고, 이 값은 2038년 1월 19일 03:14:07 UTC에 해당한다. 이 시점이 지나면 32비트 시스템에서 타임스탬프가 오버플로우돼 음수가 되거나 1970년으로 돌아가는 문제가 발생할 수 있다. 현재 대부분의 시스템은 64비트로 전환되어 있지만, 임베디드 장비나 레거시 시스템에서는 여전히 대비가 필요하다.
TIP JavaScript의 Date.now()는 밀리초를 반환하고, Python의 time.time()은 초(소수점 포함)를 반환한다. 언어마다 기본 단위가 다르니 API 연동 시 단위를 꼭 확인하자.