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으로 끝납니다. 정상입니다.