Unix 타임스탬프 변환기
Unix 타임스탬프와 날짜를 즉시 상호 변환
처리 중…
0.0
멈춘 것이 아닙니다. 계산이 끝나면 결과가 표시됩니다.
Unix 타임스탬프 변환기 소개
Unix 타임스탬프는 1970년 1월 1일 00:00:00 UTC부터 지난 초를 센 정수입니다. 서버 로그, 데이터베이스 컬럼, API 응답의 created_at 같은 곳에 1789000000 같은 숫자로 들어 있고, 이 도구는 그 숫자를 사람이 읽는 날짜로, 날짜를 다시 숫자로 바꿉니다.
숫자 자체에는 시간대가 없습니다. 같은 1790035200이 서울에서는 2026년 9월 22일 오전 9시, UTC로는 같은 날 0시입니다. 헷갈리는 지점은 대부분 단위(초인가 밀리초인가)와 시간대 표시에서 생깁니다.
10자리면 초, 13자리면 밀리초
Unix 시간은 원래 초 단위지만 JavaScript의 Date.now(), Java의 System.currentTimeMillis()는 밀리초를 돌려줍니다. 그래서 같은 순간이 1789000000(10자리)으로도, 1789000000000(13자리)으로도 저장됩니다. 밀리초 값을 초로 착각해 변환하면 서기 5만 년대 날짜가 나오고, 반대로 초 값을 밀리초로 넣으면 1970년 1월 21일쯤이 나옵니다. 결과가 1970년 근처이거나 터무니없이 먼 미래라면 단위부터 의심하세요.
이 도구는 정수부 자릿수로 단위를 판단합니다. 지금 시각은 초로 10자리, 밀리초로 13자리, 마이크로초로 16자리, 나노초로 19자리이므로 11자리 이하는 초, 12~14자리는 밀리초, 15~17자리는 마이크로초, 18~19자리는 나노초로 읽습니다(Go나 트레이싱 도구의 나노초 값도 그대로 넣으면 됩니다). ISO 8601 변환기도 같은 규칙을 씁니다. 초 단위 타임스탬프는 2001년 9월 9일(1000000000)부터 10자리가 됐고 2286년까지 10자리로 유지되므로, 현재 쓰이는 값에서는 이 경계가 잘 맞습니다. 1789000000.5처럼 소수점이 붙은 값은 초로 읽고, 결과는 초 단위로 잘라 표시합니다.
2038년 1월 19일 03:14:07 UTC
부호 있는 32비트 정수로 담을 수 있는 가장 큰 값은 2^31 − 1 = 2147483647입니다. 이 값을 변환하면 2038-01-19T03:14:07Z가 나오고, 1초 뒤인 2147483648은 32비트 변수에서 음수로 넘어가 1901년 12월로 돌아갑니다. 이것이 「2038년 문제」입니다.
최근 운영체제와 언어는 대부분 64비트 time_t를 쓰지만, 오래된 임베디드 장비, 32비트 정수로 선언된 DB 컬럼(MySQL의 TIMESTAMP 타입도 2038-01-19 03:14:07 UTC가 상한입니다), 파일 포맷 안의 4바이트 필드는 여전히 남아 있습니다. 만기일이 12년 넘게 남은 계약이나 인증서 날짜를 다루는 시스템이라면 지금 이미 이 경계를 넘는 값을 저장하게 됩니다.
윤초는 세지 않는다
POSIX 규격은 「Epoch 이후 초」를 하루를 정확히 86400초로 보고 계산하도록 정합니다. 1972년 이후 UTC에는 윤초가 27번 들어갔지만 Unix 시간에는 반영되지 않습니다. 마지막 윤초인 2016-12-31T23:59:60Z는 Unix 시간으로 표현할 수 없고, 많은 시스템이 그 1초 동안 같은 값을 반복하거나 앞뒤 시간을 조금씩 늘려(leap smear) 흡수했습니다.
그래서 두 타임스탬프의 차이는 실제 경과한 SI 초와 최대 27초 다를 수 있습니다. 일상적인 로그 분석에는 영향이 없지만, 위성 항법이나 과학 측정처럼 초 단위 정밀도가 필요한 곳에서는 TAI나 GPS 시간을 따로 씁니다. 2022년 국제도량형총회는 늦어도 2035년까지 윤초 삽입을 중단하기로 결의했습니다. 이 도구도 23:59:60 같은 시각은 입력받지 않습니다.
KST·JST 로 바꿀 때
한국 표준시(KST)와 일본 표준시(JST)는 모두 UTC+9이고 현재 서머타임이 없습니다. 그래서 UTC 시각에 9시간을 더하면 되지만, 날짜가 바뀌는 경계를 조심해야 합니다. UTC 15:00 이후의 이벤트는 한국·일본에서는 다음 날입니다. 「어제 들어온 주문」을 UTC 기준 날짜로 집계하면 한국 오전 0시~9시 주문이 전날로 잡힙니다.
날짜·시간 입력란은 브라우저가 알려 주는 내 컴퓨터의 시간대로 해석합니다. 다른 시간대의 시각을 타임스탬프로 바꾸려면 그 시간대 기준으로 UTC를 먼저 계산하거나, 오프셋을 직접 고를 수 있는 ISO 8601 변환기를 쓰세요.
예시
초와 밀리초
- 입력
1789000000 / 1789000000000- 결과
둘 다 2026-09-10T00:26:40.000Z (앞은 초, 뒤는 밀리초로 감지)
한국 시각으로는 2026년 9월 10일 오전 9시 26분 40초입니다.
2038년 경계
- 입력
2147483647 / 2147483648- 결과
2038-01-19T03:14:07.000Z / 2038-01-19T03:14:08.000Z
이 도구는 64비트 부동소수점으로 계산하므로 뒤 값도 정상으로 나옵니다. 32비트 시스템에서는 뒤 값이 −2147483648로 넘어갑니다.
서울 오전 9시
- 입력
날짜·시간: 2026-09-22 09:00 (KST 환경)- 결과
1790035200
UTC 2026-09-22 00:00과 같은 값입니다. 도쿄 오전 9시도 같은 숫자입니다.
음수 타임스탬프
- 입력
-1- 결과
1969-12-31T23:59:59.000Z
1970년 이전은 음수로 표현합니다. 생년월일을 타임스탬프로 저장하는 시스템에서 가끔 보입니다.
사용 방법
- 타임스탬프 칸에 숫자를 붙여 넣으면 단위를 감지해 UTC, 내 시간대, 상대 시간을 보여 줍니다.
- 반대 방향은 날짜·시간 칸에 시각을 넣으면 초와 밀리초 값이 나옵니다.
- 「지금」 버튼으로 현재 타임스탬프를 가져올 수 있습니다.
자주 묻는 질문
변환했더니 1970년 1월로 나옵니다.
초 단위 값을 밀리초로 해석했거나, 값이 너무 작은 경우입니다. 13자리 미만인지, 앞자리가 잘리지 않았는지 확인하세요.
타임스탬프에 시간대가 들어 있나요?
아닙니다. 항상 UTC 기준의 경과 초이고, 시간대는 표시할 때만 적용됩니다.
엑셀 날짜 숫자(예: 46287)도 변환되나요?
아닙니다. 엑셀 일련번호는 1900년 기준 일수라서 체계가 다릅니다. 이 도구에 넣으면 1970년 1월의 한 시각으로 잘못 나옵니다.
2038년 이후 날짜도 되나요?
됩니다. 브라우저의 Date는 약 ±27만 년 범위를 다룹니다. 문제는 그 값을 받아 저장하는 쪽 시스템입니다.
상대 시간의 「3개월 전」은 정확한가요?
대략입니다. 한 달을 30일, 1년을 365일로 보고 반올림합니다.
출처
- POSIX.1-2024 Base Definitions, 4.19 Seconds Since the Epoch (The Open Group)
- IERS Bulletin C (leap second announcements)
- BIPM, CGPM 2022 Resolution 4 on the use and future development of UTC
- MDN, Date (JavaScript) — time value in milliseconds
기준일: