유닉스 타임스탬프 변환

로그 파일을 들여다보거나 API 응답을 받아 보면 1700000000 같은 정체 모를 숫자가 시간 자리에 들어 있는 경우가 많습니다. 사람이 읽기 좋은 "2023년 11월 15일"이 아니라 그냥 큰 정수 하나로 시각을 표현한 것인데, 이것이 바로 유닉스 타임스탬프입니다. 컴퓨터끼리 시간을 주고받을 때는 이렇게 숫자 하나로 다루는 편이 훨씬 단순하고 오류도 적기 때문에, 거의 모든 프로그래밍 언어와 데이터베이스가 이 방식을 기본으로 씁니다. 이 글에서는 유닉스 타임스탬프가 무엇을 의미하는지, 왜 초와 밀리초를 헷갈리면 안 되는지, 타임존은 어떻게 처리해야 하는지, 그리고 한 번쯤 들어봤을 2038년 문제까지 차근차근 정리합니다. 숫자와 날짜를 직접 바꿔 보고 싶다면 유닉스 타임스탬프 변환 도구를 함께 열어 두고 읽으면 이해가 훨씬 빠릅니다.

한눈에 보기

• 유닉스 타임스탬프는 1970년 1월 1일 00:00:00 UTC(에포크)부터 흐른 초의 개수입니다.
• 값이 0이면 1970년, 약 17억(예: 1700000000)이면 2023년경입니다.
• 자바스크립트 Date.now()는 밀리초(초 × 1000)를 돌려주므로 서버·DB의 초 단위와 섞으면 1000배 오차가 납니다.
• 타임스탬프 값 자체는 UTC 기준이라 타임존과 무관하며, 화면에 표시할 때만 지역 시간대로 변환합니다.
• 32비트 정수로 저장하면 2038년 1월 19일에 오버플로가 발생하는데, 64비트로 저장하면 해결됩니다.

유닉스 타임스탬프와 에포크 시간은 다른 건가요? 같은 것을 가리키는 다른 이름입니다. 둘 다 1970년 1월 1일 00:00:00 UTC를 기준으로 흐른 초를 의미하며, POSIX 시간이라는 표현도 함께 쓰입니다.

받은 숫자가 초인지 밀리초인지 어떻게 구분하나요? 자릿수로 짐작할 수 있습니다. 현재 시점 기준으로 초 단위는 10자리, 밀리초 단위는 13자리입니다. 확실히 하려면 유닉스 타임스탬프 변환 도구에 넣어 나오는 날짜가 현재와 비슷한지 확인하면 됩니다.

타임스탬프에는 왜 타임존을 같이 저장하지 않나요? 타임스탬프 자체가 이미 UTC 기준의 절대 시각이라 타임존이 필요 없기 때문입니다. 지역 시간대는 화면에 표시할 때만 적용하면 되고, 저장·계산 단계에서는 단일 기준을 유지하는 편이 오류를 줄입니다.

2038년 문제는 지금 내 서비스에도 영향이 있나요? 64비트 정수를 사용하는 최신 환경이라면 사실상 영향이 없습니다. 다만 32비트로 시간을 저장하는 오래된 시스템이나 임베디드 장비를 쓴다면 미리 64비트로 전환해 두는 것이 안전합니다.

음수 타임스탬프도 가능한가요? 가능합니다. 에포크인 1970년 이전 시각은 음수로 표현됩니다. 예를 들어 1969년의 어떤 시각은 0보다 작은 값을 가집니다.