Unix 시간에서 초·밀리초·시간대를 구분하는 법

숫자의 자릿수보다 계약을 확인하기

현재 시점의 Unix 초와 밀리초는 자릿수가 다르게 보이는 경우가 많지만 자릿수만으로 자동 판단하면 작은 값과 오래된 날짜에서 틀릴 수 있습니다. API 문서에 timestamp가 seconds인지 milliseconds인지 명시해야 합니다. 필드 이름에 _ms 또는 _seconds를 붙이는 방식도 도움이 됩니다.

JavaScript Date 생성자에 숫자를 넣으면 밀리초로 읽습니다. Unix 초 값을 넣으려면 1,000을 곱해야 합니다. 0은 두 단위에서 같은 기준 순간을 가리키지만 1은 초라면 1초 뒤, 밀리초라면 0.001초 뒤입니다. 예제를 0만 시험하면 이 차이를 놓칠 수 있습니다.

Unix 초: 1 → 1970-01-01T00:00:01.000Z
Unix 밀리초: 1 → 1970-01-01T00:00:00.001Z
JavaScript: new Date(seconds * 1000)

한 순간을 두 시간대로 표시하기

UTC와 서울 시간이 다른 것은 저장된 순간이 바뀐 것이 아니라 표시하는 시간대가 달라진 것입니다. 1970-01-01T00:00:00.000Z는 서울에서는 오전 9시입니다. 로그를 비교할 때는 원본 저장 기준과 화면 표시 기준을 함께 적어야 다른 이벤트로 착각하지 않습니다.

도구는 UTC ISO 문자열과 Asia/Seoul 표시를 함께 출력합니다. 브라우저가 다른 국가의 로컬 시간으로 설정돼 있어도 서울 표시는 지정한 시간대를 사용합니다. 일정 데이터는 모든 순간이 Unix 숫자와 같지는 않습니다. '매일 오전 9시' 같은 반복 일정은 지역 시간대 규칙을 따로 저장해야 합니다.

UTC: 1970-01-01T00:00:00.000Z
서울 표시: 1970-01-01 09:00
두 표현은 같은 순간
반복 일정은 별도 시간대 규칙 필요

시간대 없는 ISO 문자열을 제한하는 이유

2026-10-03T09:00:00처럼 시간대가 없는 문자열은 처리 환경에 따라 로컬 시간으로 해석될 수 있습니다. 테스트 PC와 서버의 설정이 다르면 같은 원문으로 다른 순간을 얻습니다. 도구는 Z 또는 +09:00처럼 오프셋을 명시한 문자열만 받아 이런 암묵적 해석을 줄입니다.

2026-10-03T09:00:00+09:00은 2026-10-03T00:00:00Z와 같은 순간입니다. 출력 비교에서는 둘의 Unix 밀리초가 같은지 확인할 수 있습니다. 브라우저가 문자열을 읽었다는 사실만으로 잘못된 날짜가 정상화되지 않았다고 보장할 수 없으므로 원래 API의 날짜 검증 규칙도 필요합니다.

실무 검수 순서

초·밀리초·음수값·시간대 문자열을 각각 예제로 넣어 봅니다. 파일 이름에 날짜를 쓸 때는 UTC 기준인지 서울 기준인지 정하고, 일별 통계를 자를 때는 서울의 자정이 UTC에서 언제인지 계산합니다. 날짜만 저장하는 생일·기념일을 시각으로 바꿀 때는 의도하지 않은 전날 이동도 확인합니다.

자료를 전달할 때 값만 복사하지 말고 단위·시간대·출력 형식 설명을 함께 남기세요. 로그의 실제 사건 시각과 수집 시각은 다를 수 있으므로 필드도 구분합니다. 타임스탬프 변환은 시계 동기화나 서버 지연을 조사하는 기능이 아니며, 저장된 값의 표현을 일관되게 비교하는 도구입니다.