API 응답에서 "created_at": 1740787200이라는 값을 받았다. 이게 날짜라는 건 알겠는데, 2025년인지 2026년인지 눈으로는 도저히 알 수 없다. Unix 타임스탬프는 사람이 읽기 위한 형식이 아니라 컴퓨터가 시간을 처리하기 위한 숫자이기 때문이다.
Unix 타임스탬프란
1970년 1월 1일 00:00:00 UTC(이를 "Epoch"라 부른다)부터 현재까지 경과한 초(seconds)의 수다.
0= 1970년 1월 1일 00:00:00 UTC1000000000= 2001년 9월 9일1740787200= 2025년 3월 1일1772323200= 2026년 3월 1일
하나의 숫자로 날짜와 시간을 동시에 표현할 수 있고, 시간대(타임존)와 무관하게 절대적인 시점을 나타낸다. 그래서 데이터베이스, API, 로그 시스템에서 시간을 저장하는 표준 방식으로 쓰인다.
초(seconds) vs 밀리초(milliseconds)
타임스탬프를 다룰 때 가장 흔한 실수가 단위 혼동이다.
| 단위 | 자릿수 | 예시 | 사용처 |
|---|---|---|---|
| 초 | 10자리 | 1740787200 | PHP, Python, MySQL |
| 밀리초 | 13자리 | 1740787200000 | JavaScript, Java, MongoDB |
TIP 10자리면 초, 13자리면 밀리초로 구분하면 된다. 밀리초를 초로 바꾸려면 1000으로 나누고, 반대는 1000을 곱한다.
왜 날짜 문자열 대신 타임스탬프를 쓰나
- 시간대 독립적
- "2026-03-01 09:00:00"은 한국 시간인지 미국 시간인지 알 수 없다. 타임스탬프는 UTC 기준 절대값이라 해석이 명확하다.
- 비교와 정렬이 쉽다
- 숫자니까 대소 비교만 하면 시간순 정렬이 된다. 문자열 날짜는 포맷에 따라 정렬이 꼬일 수 있다.
- 연산이 간단하다
- "30일 후"를 구하려면 2,592,000(30 × 24 × 60 × 60)을 더하면 된다.
변환 방법
코드로
// JavaScript
new Date(1740787200 * 1000).toISOString();
// "2025-03-01T00:00:00.000Z"
// Python
import datetime
datetime.datetime.fromtimestamp(1740787200)
# 2025-03-01 09:00:00 (KST)
도구로
디버깅 중에 로그의 타임스탬프가 어떤 시점인지 빠르게 확인하고 싶을 때는 타임스탬프 변환기에 숫자를 넣으면 로컬 시간, UTC, ISO 8601 형식으로 바로 나온다. 반대로 날짜를 입력해서 타임스탬프를 구하는 것도 가능하다. 현재 시각의 타임스탬프도 실시간으로 표시되니까 테스트 데이터를 만들 때 바로 복사해서 쓸 수 있다.
2038년 문제
32비트 시스템에서 Unix 타임스탬프는 최대 2,147,483,647까지 저장할 수 있다. 이 값에 해당하는 시점이 2038년 1월 19일이다. 이 날짜를 넘기면 32비트 정수가 오버플로우를 일으켜 1970년으로 돌아가는 버그가 발생한다. 현재 대부분의 시스템은 64비트로 전환되어 이 문제를 해결했지만, 오래된 임베디드 장비에서는 여전히 주의가 필요하다.
타임스탬프는 개발에서 매일 마주치는 개념이다. 10자리인지 13자리인지, UTC인지 로컬인지만 정확히 구분하면 시간 관련 버그의 대부분을 예방할 수 있다.