Unix 타임스탬프 변환기

타임스탬프 변환 공식

Unix 타임스탬프 = 1970-01-01 00:00:00 UTC부터 흐른 초 / 밀리초 = 초 × 1,000 / 마이크로초 = 초 × 1,000,000 / 나노초 = 초 × 1,000,000,000

시간 변환에서 자주 틀리는 지점

• 같은 순간이라도 언어와 런타임마다 단위가 다릅니다. `date +%s`와 Go의 Unix()는 초, 자바스크립트 Date.now()와 자바 currentTimeMillis()는 밀리초, Go의 UnixNano()는 나노초를 냅니다.
• 자릿수로 단위를 가려냅니다. 초는 2001년에 10자리가 되어 2286년까지 10~11자리이고, 밀리초는 같은 기간 13자리라 겹치지 않습니다.
• 타임스탬프 자체에는 시간대가 없습니다. 같은 숫자가 서울에서는 18시, 런던에서는 9시로 보일 뿐 가리키는 순간은 하나입니다. 그래서 KST와 UTC를 함께 표시합니다.
• 2038년 1월 19일 03:14:07 UTC를 넘으면 32비트 부호 있는 정수에 초를 담던 시스템에서 값이 넘칩니다. 그 시각을 넘는 값을 넣으면 경고가 표시됩니다.
• Unix 시간은 윤초를 세지 않습니다. 하루를 항상 정확히 86,400초로 보기 때문에, 실제 흐른 SI 초와는 몇 초 차이가 납니다.
• 음수는 1970년 이전을 뜻합니다. -86400은 1969년 12월 31일입니다.

이런 때 유용해요

• 로그에 남은 1755388800을 넣으면 10자리라 초로 읽어 2025년 8월 17일 09시(KST)로 변환됩니다.
• 자바 로그의 1755388800000은 13자리라 밀리초로 읽어 같은 시각을 가리킵니다. 단위를 잘못 잡으면 55000년대가 나오므로 표시된 단위를 확인하세요.
• 데이터베이스에 넣을 값이 필요하면 날짜 → 타임스탬프로 바꿔 초 또는 밀리초를 복사합니다.

자주 묻는 질문

초인지 밀리초인지 어떻게 구분하나요?

자릿수를 보면 됩니다. 지금 시점에서 초는 10자리, 밀리초는 13자리입니다.

초 값을 밀리초로 잘못 읽으면 1970년대 초반이 나오고, 반대로 읽으면 5만 년대가 나오므로 결과가 터무니없으면 단위를 의심하면 됩니다. 이 도구는 자릿수로 짐작한 단위를 항상 함께 보여 줍니다.

왜 내 시스템 시각과 몇 초 다른가요?

브라우저는 운영체제 시계를 그대로 씁니다. NTP 동기화가 안 된 기기라면 몇 초에서 몇 분까지 어긋날 수 있습니다. 정확한 값이 필요하면 서버에서 받은 시각과 비교하세요.

ISO 8601의 Z와 +09:00은 무엇이 다른가요?

가리키는 순간은 같고 표기 기준만 다릅니다. Z는 UTC 기준이라는 뜻이고 +09:00은 UTC보다 9시간 빠른 시간대에서 본 표기입니다.

2026-08-17T09:00:00Z와 2026-08-17T18:00:00+09:00은 같은 순간입니다.

2038년 문제가 지금도 문제가 되나요?

대부분의 현대 시스템은 64비트 정수를 쓰므로 괜찮습니다. 다만 오래된 임베디드 기기나 32비트 time_t를 쓰는 C 코드, 일부 데이터베이스 칼럼 타입에는 남아 있습니다.

만기가 2038년을 넘는 금융 데이터처럼 미래 날짜를 다루면 지금도 마주칠 수 있습니다.

참고 자료

• IETF RFC 3339 – Date and Time on the Internet
• MDN — Date.now()

이용 시 유의사항

입력한 내용은 브라우저 안에서만 처리됩니다. 표시되는 현지 시각은 사용 중인 기기의 시간대 설정을 따르므로, 다른 시간대의 값을 확인할 때는 UTC 표기를 기준으로 보세요.