JWT 만료 시간 확인
iat, exp, nbf 같은 숫자 값을 사람이 읽을 수 있는 날짜로 바꿔서 인증 문제를 빠르게 확인할 수 있습니다.
Current Time
Converter
↔
유닉스 타임스탬프 변환
브라우저 내부 처리
Convert between Unix timestamps and human-readable dates.
타임스탬프 변환이 자주 필요한 이유
로그와 모니터링 해석
서버 로그에 남은 epoch 값을 로컬 시각과 UTC로 같이 비교하면 장애 시점과 사용자 신고 시간을 더 정확하게 맞출 수 있습니다.
캠페인과 예약 시간 검수
광고 집행, 배치 작업, 예약 발송 시간을 초와 밀리초 단위로 오가는 과정에서 단위 실수를 줄이는 데 도움이 됩니다.
실무에서 많이 헷갈리는 포인트
초와 밀리초를 어떻게 구분하나요?
보통 10자리면 초, 13자리면 밀리초인 경우가 많습니다. 자릿수가 애매하면 원본 시스템 문서나 샘플 값과 함께 확인하는 것이 안전합니다.
로컬 시간과 UTC가 왜 둘 다 필요한가요?
사용자에게 보여주는 시간은 로컬이 편하고, 시스템 간 비교나 로그 상관관계 확인은 UTC가 더 정확하기 때문입니다.
이 페이지에서 업로드되는 데이터가 있나요?
타임스탬프와 날짜 계산은 브라우저 안에서 처리됩니다. 다만 운영 환경의 보안 정책과 브라우저 확장 상태는 별도로 확인해 주세요.
타임스탬프를 다룰 때
초와 밀리초를 자릿수로 구분하세요
Unix 타임스탬프가 10자리면 초, 13자리면 밀리초입니다. 밀리초를 초로 읽으면 1970년대가 나오고, 초를 밀리초로 읽으면 수만 년 뒤가 나옵니다. 값이 터무니없으면 계산이 틀린 게 아니라 단위를 잘못 읽은 것입니다.
epoch는 항상 UTC입니다
Unix 타임스탬프 자체에는 시간대 정보가 없습니다. 그래서 같은 숫자가 서울에서는 오후 6시, 런던에서는 오전 9시로 표시됩니다. 로그를 비교할 때 두 서버의 표시 시간대가 다르면 같은 사건이 다른 시각으로 보입니다.
2038년 문제는 아직 남아 있습니다
32비트 부호 있는 정수로 초를 저장하는 시스템은 2038년 1월에 넘칩니다. 오래된 임베디드 장비나 레거시 데이터베이스 컬럼에서 여전히 발견됩니다. 만료일이나 미래 날짜를 다루는 곳이라면 컬럼 타입을 확인해두는 편이 좋습니다.
자주 만나는 오류
날짜가 1970년으로 나올 때
밀리초 값을 초로 해석했거나 그 반대입니다. 1000배 차이라 밀리초를 초로 읽으면 5만 년 후가, 초를 밀리초로 읽으면 1970년 초가 나옵니다.
9시간이 어긋날 때
epoch는 항상 UTC 기준입니다. 표시할 때 로컬 타임존이 적용되어 한국은 +9시간입니다. 로그를 비교할 때는 양쪽이 어느 기준으로 찍혔는지 먼저 확인하세요.
2038년 문제
32비트 부호 있는 정수로 초를 저장하면 2038년 1월 19일에 넘칩니다. 오래된 시스템이나 DB 컬럼 타입을 다룰 때는 64비트인지 확인해두는 편이 좋습니다.
사용 순서와 입력 예시 더 보기
실제 입력과 결과
초 단위 epoch 변환
입력
1767225600결과
2026-01-01 00:00:00 UTC
2026-01-01 09:00:00 KST밀리초 단위 값
입력
1767225600000결과
2026-01-01 00:00:00 UTC자릿수가 10개면 초, 13개면 밀리초입니다. 이 기준으로 먼저 구분하세요.