타임스탬프 변환기

UNIX 타임스탬프란

**1970년 1월 1일 0시 0분 0초(UTC)**부터 흐른 시간을 숫자 하나로 표현한 것입니다. 이 기준점을 **에포크(epoch)**라고 부릅니다.

시간대가 없는 절대 시각이라는 점이 핵심입니다. 서울에서 만들든 뉴욕에서 만들든 같은 순간이면 같은 숫자입니다. 그래서 서버와 클라이언트가 시간을 주고받을 때 가장 안전한 형식입니다.

초와 밀리초 구분하기

자릿수로 판별할 수 있습니다.

| 자릿수 | 단위 | 대략적인 시기 | |---|---|---| | 10자리 | 초 | 2001년 ~ 2286년 | | 13자리 | 밀리초 | 2001년 ~ 2286년 |

초 단위로 13자리 값은 서기 33만 년쯤이 되어 현실적인 날짜가 아닙니다. 그래서 자릿수만 봐도 거의 확실히 구분됩니다.

이 도구는 입력값이 1조를 넘으면 밀리초로 자동 판별합니다.

1000배 어긋나는 버그

이 혼동은 실무에서 가장 흔한 시간 관련 버그입니다.

• JWT의 exp, iat, nbf — 모두 초 단위입니다. 자바스크립트의 Date.now()는 밀리초라 그대로 넣으면 1000배 큰 값이 됩니다.
• 자바스크립트 new Date() — 밀리초를 받습니다. 초 단위 값을 넣으면 1970년 근처로 나옵니다.
• PHP time(), Python time.time() — 초 단위입니다.
• Java System.currentTimeMillis() — 밀리초입니다.

만든 쪽과 읽는 쪽의 단위를 항상 확인하세요.

2038년 문제

32비트 부호 있는 정수로 초 단위 타임스탬프를 저장하는 시스템은 **2038년 1월 19일 03:14:07(UTC)**에 표현 한계에 도달합니다. 그 다음 초에 값이 넘쳐 음수가 되면서 1901년으로 돌아갑니다.

2000년 문제와 비슷한 구조지만 이쪽이 더 근본적입니다. 날짜를 어떻게 표기했느냐가 아니라 저장 타입의 물리적 한계이기 때문입니다.

현대의 64비트 시스템과 자바스크립트는 해당하지 않습니다. 다만 다음은 여전히 위험합니다.

• 오래된 임베디드 장비와 산업용 제어기
• INT 타입으로 타임스탬프를 저장한 데이터베이스 컬럼
• 32비트로 컴파일된 레거시 애플리케이션

만기가 긴 계약이나 장기 보관 데이터를 다룬다면 지금 확인해 둘 가치가 있습니다.

시간대는 표시할 때만 붙습니다

타임스탬프 자체에는 시간대가 없습니다. 사람이 읽는 형태로 바꿀 때 비로소 시간대가 적용됩니다.

같은 1756000000이 한국에서는 2025년 8월 24일 저녁으로, 런던에서는 같은 날 낮으로 보입니다. 이 도구는 UTC와 브라우저 현지 시각을 모두 보여줍니다. 한국은 UTC보다 9시간 빠르므로 두 값이 9시간 차이 나는 것이 정상입니다.

한국은 서머타임이 없어 연중 UTC+9로 고정입니다. 서머타임을 쓰는 지역을 다룬다면 오프셋이 계절에 따라 바뀐다는 점을 고려해야 합니다.

ISO 8601을 쓰세요

사람과 시스템이 함께 읽어야 하는 곳에서는 ISO 8601 형식이 좋습니다.

2026-08-27T12:34:56.000Z

끝의 Z는 UTC를 뜻합니다. +09:00처럼 오프셋을 명시할 수도 있습니다.

2026-08-27 12:34:56처럼 오프셋 없는 형식은 피하세요. 이 값이 UTC인지 현지 시각인지 알 수 없어, 시스템 간에 주고받으면 9시간 어긋나는 사고가 반복적으로 생깁니다.

데이터베이스에 저장할 때

PostgreSQL — TIMESTAMPTZ를 쓰세요. 내부적으로 UTC로 저장하고 조회 시 세션 시간대로 변환합니다. TIMESTAMP(시간대 없음)는 같은 문제를 그대로 안고 있습니다.

MySQL — TIMESTAMP는 UTC로 저장되지만 2038년 한계가 있습니다. DATETIME은 한계가 없는 대신 시간대 변환을 하지 않습니다.

가장 안전한 선택은 UTC로 저장하고 표시할 때만 변환하는 것입니다. 예외 없이 이 원칙을 지키면 시간 관련 버그가 크게 줄어듭니다.

함께 확인하면 좋은 것

토큰의 만료 시각을 확인하려면 JWT 디코더를, 스케줄 표현식은 Cron 표현식 해석기를 이용하세요.