유닉스 타임스탬프 읽는 법: 초와 밀리초 구분, 시간대, 2038년 문제

유닉스 타임스탬프의 기준(1970-01-01 UTC), 10자리 초와 13자리 밀리초 구분법, 한국 시간(KST) 변환, 데이터베이스와 자바스크립트에서 자주 생기는 오류, 2038년 문제를 정리합니다.

로그 파일, API 응답, 데이터베이스에서 1791817200 같은 숫자를 만나면 그것이 언제인지 바로 알기 어렵습니다. 유닉스 타임스탬프는 시간대와 날짜 형식에 상관없이 시각을 하나의 숫자로 저장하는 방식이라 개발과 데이터 작업에 널리 쓰입니다.

기본 개념

기준 시각(에포크)은 1970년 1월 1일 00:00:00 UTC입니다. 타임스탬프 0이 이 순간이고, 1이 늘 때마다 1초가 지난 것입니다. 예를 들어 1791817200은 2026년 10월 12일 15:00:00 UTC, 한국 시간으로는 2026년 10월 13일 00:00:00입니다.

초인지 밀리초인지 구분하기

가장 흔한 실수는 밀리초 값을 초로 해석하는 것입니다. 13자리 값을 초로 변환하면 수만 년 뒤 날짜가 나오고, 반대로 10자리 값을 밀리초로 해석하면 1970년 1월의 날짜가 나옵니다. 변환 결과가 1970년이나 먼 미래라면 단위부터 확인하세요.

시간대는 표시할 때만 붙습니다

같은 타임스탬프는 서울에서 보든 뉴욕에서 보든 같은 순간을 가리킵니다. 표시할 때 UTC+9를 적용하면 한국 시간이 됩니다. 문제는 날짜 문자열을 타임스탬프로 바꿀 때 생깁니다. "2026-10-13 00:00"을 변환할 때 시간대를 지정하지 않으면 서버 설정에 따라 UTC로 해석되어 9시간 차이가 날 수 있습니다. 저장은 UTC 기준 타임스탬프로 하고, 화면에 표시할 때만 사용자 시간대로 바꾸는 것이 안전한 원칙입니다.

자주 생기는 오류

• 자바스크립트: new Date(1791817200)은 1970년 1월로 해석됩니다. 초 단위 값이면 new Date(1791817200 * 1000)처럼 1,000을 곱해야 합니다.
• 엑셀: 엑셀 날짜는 1900년 기준 일 수라서 타임스탬프를 그대로 넣으면 안 됩니다. 한국 시간으로 보려면 =(A1+9*3600)/86400+DATE(1970,1,1)처럼 변환합니다.
• 하루 경계: UTC 자정은 한국 시간 오전 9시입니다. "하루 단위 집계"를 UTC로 하면 한국 사용자의 하루와 어긋납니다.

2038년 문제

타임스탬프를 32비트 부호 있는 정수로 저장하는 시스템은 최댓값 2,147,483,647을 넘을 수 없습니다. 이 값은 2038년 1월 19일 03:14:07 UTC이고, 1초 뒤에는 음수로 넘어가 1901년으로 표시되는 오류가 생길 수 있습니다. 최신 운영체제와 언어 대부분은 64비트를 쓰지만, 오래된 임베디드 기기나 데이터베이스의 INT 컬럼, 오래된 파일 형식은 여전히 확인이 필요합니다. 미래 날짜(만기일, 보증 기간)를 저장하는 시스템이라면 지금 점검해 두는 것이 좋습니다.

윤초는 세지 않습니다

유닉스 시간은 하루를 항상 86,400초로 계산하고 윤초를 반영하지 않습니다. 그래서 두 타임스탬프의 차이는 실제 경과 초와 몇 초 다를 수 있지만, 일반적인 서비스 개발에서는 문제가 되지 않습니다.

자주 묻는 질문

참고한 공식 자료

• MDN Date.now()

이 글은 일반적인 기준을 설명하는 정보이며 개인별 법률·세무 판단을 대신하지 않습니다. 중요한 결정 전에는 본문에 적은 공식 기관 자료나 전문가 상담으로 확인하세요. 내용 오류는 문의 페이지로 알려주시면 확인 후 수정합니다.