Unix 타임스탬프 변환 · 날짜 ↔ 초·밀리초

로그나 DB에 찍힌 숫자를 사람이 읽는 시각으로 바꾸거나, 특정 시각의 타임스탬프를 구합니다. 비워 두면 현재 시각을 보여주고, 10자리면 초, 13자리면 밀리초로 자동 판단합니다.

비워 두면 현재 시각. 시간대 표기가 없는 날짜는 한국 시간(KST)으로 해석
Unix 타임스탬프 변환 · 날짜 ↔ 초·밀리초모두의계산기

Unix 타임스탬프란

1970년 1월 1일 0시 0분 0초 UTC(에포크)부터 흐른 초 수입니다. 시간대 정보가 없는 하나의 숫자라서 서버·DB·로그에서 시각을 저장하는 표준처럼 쓰입니다. 같은 순간은 서울에서도 뉴욕에서도 같은 숫자이고, 사람이 읽는 형태로 바꿀 때 비로소 시간대가 개입합니다. 이 도구는 브라우저 안에서만 계산하며 입력을 전송하지 않습니다.

초와 밀리초 혼동

Unix 시스템·Python·PHP는 초 단위(10자리), 자바스크립트 Date.now()·Java System.currentTimeMillis()는 밀리초(13자리)를 씁니다. 밀리초 값을 초로 해석하면 5만 년 뒤가 나오고, 초 값을 밀리초로 해석하면 1970년 1월 20일 근처가 나옵니다. 결과가 1970년 1월이나 수만 년 뒤라면 단위를 잘못 짚은 것입니다. 자동 모드는 절댓값 1000억(1e11) 이상을 밀리초로 봅니다. 초 단위로 1e11은 서기 5138년이므로 실사용에서 겹칠 일은 없습니다. 소수점이 있는 초 값(1700000000.123)은 초로 해석해 밀리초 부분을 살립니다.

2038년 문제

32비트 부호 있는 정수로 초를 저장하면 최댓값이 2,147,483,647이며 이것이 2038년 1월 19일 03:14:07 UTC입니다. 그 다음 초에 값이 음수로 넘어가 1901년으로 돌아갑니다. 오래된 임베디드 장비, 32비트 time_t를 쓰는 C 프로그램, MySQL의 TIMESTAMP 컬럼(2038-01-19까지만 저장 가능)이 영향을 받습니다. 새 시스템은 64비트를 쓰므로 문제없지만, 만료일을 먼 미래로 잡는 코드가 이 범위를 넘으면 예상치 못한 과거 날짜가 됩니다. 이 도구는 해당 값을 넘으면 경고를 표시합니다.

KST와 ISO 8601 표기

한국 표준시는 UTC+9이고 서머타임이 없으므로 연중 오프셋이 같습니다. ISO 8601에서 끝의 Z는 UTC를, +09:00은 KST를 뜻합니다. 시간대 표기가 없는 2024-03-15T09:30:00은 규격상 "지역 시간"이라 해석하는 쪽의 설정에 따라 달라집니다. 서버가 UTC로 돌면 9시간이 어긋나는 사고가 흔하니, 시스템 간에 날짜 문자열을 주고받을 때는 항상 오프셋을 붙이는 것이 안전합니다. 이 도구는 오프셋 없는 입력을 KST로 해석합니다.

윤초는 없다

Unix 시간은 하루를 항상 86,400초로 계산하며 윤초를 세지 않습니다. 그래서 실제 UTC와 드물게 1초 차이가 나지만 대부분의 소프트웨어는 이 단순화를 따릅니다.

자주 묻는 질문

결과가 1970년 1월로 나와요.

초 단위 값을 밀리초로 해석했을 때 생기는 증상입니다. 단위를 "초"로 바꿔 보세요.

날짜를 넣었는데 9시간이 어긋나요.

끝에 Z가 붙은 입력은 UTC로 해석됩니다. 한국 시간으로 넣으려면 Z를 떼거나 +09:00을 붙이세요.

밀리초가 0으로 나와요.

초 단위 타임스탬프에는 밀리초 정보가 없어 밀리초 표시가 000으로 끝납니다. 정상입니다.

함께 보기