타임스탬프 변환기

UNIX 타임스탬프란

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

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

도구 사용법

위쪽에 현재 시각의 타임스탬프가 초와 밀리초로 1초마다 갱신되어 표시됩니다. 지금 값을 코드나 API 테스트에 붙여 넣을 때 그대로 복사하면 됩니다. 아래에 숫자를 넣으면 ISO 8601, UTC, 브라우저 현지 시각, 요일, 지금 기준 상대 시간("3일 전")이 함께 나옵니다. 반대로 날짜를 넣으면 타임스탬프로 바뀌는데, 2026-09-06 12:00처럼 오프셋 없이 넣으면 브라우저 시간대(한국이면 KST) 로 해석하고, 2026-09-06T12:00:00+09:00처럼 오프셋을 붙이면 그 값을 따릅니다. 날짜만 넣으면 그날 0시입니다.

기억해 두면 좋은 값

| 타임스탬프 (초) | 시각 (UTC) | 의미 | | --------------- | ----------------------- | --------------------------------- | | 0 | 1970-01-01 00:00:00 | 에포크. 값이 0이면 초기화 안 된 것 | | 1,000,000,000 | 2001-09-09 01:46:40 | 10억 초. 이후로 10자리 | | 1,500,000,000 | 2017-07-14 02:40:00 | | | 1,700,000,000 | 2023-11-14 22:13:20 | | | 2,147,483,647 | 2038-01-19 03:14:07 | 32비트 부호 있는 정수의 최댓값 |

로그에 0이나 -1, 1970-01-01이 찍혀 있으면 실제 시각이 아니라 값이 비어 있거나 파싱에 실패한 것입니다. 1970-01-01 09:00:00으로 보인다면 0을 한국 시각으로 표시한 것이라 같은 뜻입니다. 이 도구에 0을 넣어 보면 두 표시가 어떻게 다른지 바로 확인됩니다.

초와 밀리초 구분하기

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

| 자릿수 | 단위 | 대략적인 시기 | |---|---|---| | 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시간 어긋나는 사고가 반복적으로 생깁니다.

언어별로 지금 타임스탬프 얻기

JavaScript  Date.now()                 // 밀리초
            Math.floor(Date.now()/1000) // 초
Python      int(time.time())            // 초
Java/Kotlin System.currentTimeMillis()  // 밀리초
Go          time.Now().Unix()           // 초
Shell       date +%s                    // 초

반대로 타임스탬프를 날짜로 바꿀 때 자바스크립트는 new Date(초 * 1000), 파이썬은 datetime.fromtimestamp(초, tz=timezone.utc)처럼 단위와 시간대를 명시해야 합니다. 파이썬의 fromtimestamp를 시간대 없이 부르면 실행 환경의 로컬 시간대로 바뀌어 서버(UTC)와 노트북(KST)에서 결과가 달라집니다.

로그와 API 응답에서 만나는 형태

• 1788000000 — 초. 대부분의 REST API와 리눅스 로그.
• 1788000000000 — 밀리초. 자바스크립트, 자바, 카프카 메시지.
• 1788000000123456 — 마이크로초(16자리). 일부 데이터베이스와 트레이싱 도구.
• 2026-08-29T10:40:00Z — ISO 8601. 이 도구가 함께 보여 주는 형식.
• Sat, 29 Aug 2026 10:40:00 GMT — HTTP 헤더(Date, Last-Modified)가 쓰는 형식.

16자리 이상은 이 도구가 밀리초로 판별하므로, 마이크로초 값은 뒤 세 자리를 떼고 넣으세요. 나노초(19자리)라면 여섯 자리를 뗍니다.

데이터베이스에 저장할 때

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

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

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

함께 확인하면 좋은 것

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