로그 파일을 열었더니 시간이 "1709251200"이라고 적혀 있다. 날짜가 아니라 숫자 10자리다. 이게 Unix 타임스탬프인데, 1970년 1월 1일 자정(UTC)부터 흘러간 초(second)를 세는 방식이다.
Unix 타임스탬프의 기본 원리
컴퓨터는 날짜를 "2026-03-01 09:00:00"처럼 저장하지 않는다. 대신 기준 시점(Epoch)에서 몇 초가 지났는지를 정수 하나로 표현한다.
- Epoch (기준 시점)
- 1970년 1월 1일 00:00:00 UTC. Unix 시스템이 탄생한 시기에 정해졌다.
- 타임스탬프 값
- Epoch에서 경과한 초(second) 수. 예: 1,709,251,200 = 2024년 3월 1일 00:00:00 UTC
- 밀리초 타임스탬프
- JavaScript 등 일부 환경에서는 밀리초(1/1000초) 단위를 쓴다. 13자리 숫자면 밀리초, 10자리면 초 단위다.
타임스탬프 ↔ 날짜 변환
주요 언어별 변환 코드
| 언어 | 타임스탬프 → 날짜 | 날짜 → 타임스탬프 |
|---|---|---|
| JavaScript | new Date(1709251200 * 1000) | Math.floor(Date.now() / 1000) |
| Python | datetime.fromtimestamp(1709251200) | int(datetime.now().timestamp()) |
| Java | Instant.ofEpochSecond(1709251200) | Instant.now().getEpochSecond() |
코드를 쓰지 않고 빠르게 확인하려면 타임스탬프 변환기에 숫자를 넣으면 된다. 초 단위와 밀리초 단위를 자동으로 구분하고, 로컬 시간, UTC, ISO 8601 형식으로 동시에 보여준다. 반대로 날짜를 선택하면 타임스탬프 값이 나온다.
실무에서 자주 겪는 타임스탬프 문제
1. 시간대(Timezone) 혼동
타임스탬프 자체는 UTC 기준이다. 한국 시간(KST)은 UTC+9이므로, 같은 타임스탬프라도 시간대에 따라 표시되는 시각이 다르다. 로그 분석할 때 어떤 시간대인지 확인하지 않으면 9시간 차이가 나는 데이터를 잘못 해석할 수 있다.
2. 초 vs 밀리초 구분
API에서 받은 타임스탬프가 10자리인지 13자리인지 확인해야 한다. JavaScript의 Date.now()는 밀리초(13자리)를 반환하고, 대부분의 서버 API는 초(10자리)를 쓴다. 단위를 혼동하면 1970년 날짜가 나오거나 먼 미래 날짜가 나온다.
3. 2038년 문제
32비트 정수로 저장되는 시스템에서는 2038년 1월 19일 이후 타임스탬프가 오버플로우된다. 대부분의 현대 시스템은 64비트로 전환됐지만, 레거시 시스템에서는 여전히 주의가 필요하다.
TIP 데이터베이스에 시간을 저장할 때 타임스탬프(정수)로 넣으면 시간대 변환이 자유롭고, 날짜 비교/정렬이 빠르다. 사용자에게 보여줄 때만 로컬 시간으로 변환하면 된다.
타임스탬프는 컴퓨터가 시간을 다루는 가장 기본적인 방식이다. 로그 분석, API 개발, 데이터 처리에서 매일 마주치는 개념이니 한 번 정리해두면 두고두고 쓸 수 있다.