Unix Timestamp 변환 epoch

Unix 타임스탬프(초/밀리초)와 사람이 읽는 날짜를 서로 변환합니다. 타임존별 시각도 함께 확인합니다.

current epoch · sec · ms
Timestamp → Date
Date → Timestamp
timezone:
도구 설명

이 도구가 하는 일

Unix 타임스탬프는 1970년 1월 1일 00:00:00 UTC부터 흐른 시간을 초 단위 정수로 표현한 값입니다. 시간대나 서머타임의 영향을 받지 않는 절대적인 기준점이기 때문에 데이터베이스, 로그, API에서 시각을 저장하는 표준적인 방법으로 쓰입니다.

혼란이 자주 발생하는 지점은 단위입니다. Unix 계열 시스템과 PHP, 대부분의 데이터베이스는 초 단위를 쓰지만 JavaScript의 Date.now()와 Java는 밀리초 단위를 사용합니다. 초 단위 값은 현재 10자리이고 밀리초 값은 13자리이므로 자릿수로 구분할 수 있습니다. 단위를 잘못 해석하면 1970년으로 표시되거나 수만 년 뒤의 날짜가 나옵니다.

이 도구는 두 단위를 자동으로 인식해 변환하고, 반대로 날짜를 입력해 타임스탬프를 얻을 수도 있습니다. UTC와 로컬 시간대의 값을 함께 보여주므로 서버와 클라이언트의 시각 차이를 확인할 때 유용합니다.

언제 사용하나요

로그에 기록된 타임스탬프가 실제 몇 시인지 확인할 때, API가 반환한 만료 시각이나 생성 시각을 검토할 때, JWT의 exp와 iat 값을 해석할 때, 특정 날짜의 타임스탬프를 구해 쿼리 조건에 넣을 때, 서버와 로컬의 시각 차이를 비교할 때 사용합니다.

입력과 출력 예시

입력 1715155200
출력 2024-05-08 08:00:00 UTC / 2024-05-08 17:00:00 KST

10자리는 초 단위입니다. 한국 시간은 UTC보다 9시간 빠릅니다.

입력 1767225600
출력 2026-01-01 00:00:00 UTC

JWT의 exp 값처럼 만료 시각을 확인할 때 자주 쓰는 형태입니다.

입력 1715155200000
출력 2024-05-08 08:00:00 UTC (밀리초 입력)

13자리는 밀리초 단위로 인식됩니다. JavaScript의 Date.now() 결과가 이 형태입니다.

주의사항

변환 결과를 볼 때 어느 시간대 기준인지 반드시 확인하십시오. 같은 타임스탬프라도 UTC와 한국 시간(UTC+9)은 9시간 차이가 납니다. 장애 분석에서 이 차이를 놓치면 엉뚱한 시간대의 로그를 뒤지게 됩니다. 또한 32비트 정수로 타임스탬프를 저장하는 오래된 시스템은 2038년 1월 이후의 시각을 표현할 수 없다는 문제(Year 2038 problem)가 있습니다.

자주 묻는 질문

결과가 1970년으로 나옵니다.

밀리초 값을 초로 해석했거나 값이 0에 가까운 경우입니다. 자릿수를 확인하십시오. 10자리는 초, 13자리는 밀리초입니다.

서버 시각과 9시간 차이가 납니다.

서버가 UTC 기준으로 동작하고 있을 가능성이 높습니다. 한국 시간은 UTC+9이므로 정상적인 차이입니다.

2038년 문제가 무엇인가요?

타임스탬프를 32비트 부호 있는 정수로 저장하면 2038년 1월 19일 이후를 표현할 수 없습니다. 64비트 정수를 사용하면 해결됩니다.

Copied