유닉스 타임스탬프란 무엇인가요?

이 숫자는 어떻게 정의될까

POSIX는 "에포크 이후 초"를 고정된 공식으로 정의합니다. 하루는 정확히 86,400초로 계산하며 1970-01-01T00:00:00Z부터 셉니다. 에포크 이전 시점은 음수이므로 -1은 1969-12-31T23:59:59Z입니다.

값이 UTC 기준으로 측정되므로 시간대도 서머타임도 없습니다. 이를 벽시계 시간으로 바꾸는 것은 별도의 단계이며, Asia/Tokyo나 America/New_York 같은 시간대가 필요합니다.

초, 밀리초, 그 밖의 단위

전통적인 유닉스 타임스탬프는 초 단위지만, 많은 시스템이 더 작은 단위로 저장합니다. 현재 날짜라면 자릿수로 가장 빨리 구분할 수 있습니다.

단위를 섞는 것이 가장 흔한 타임스탬프 버그입니다. 초 값을 JavaScript의 new Date()에 넘기면 1970년 1월이 되고, 밀리초 값을 초로 읽으면 수만 년 뒤가 됩니다. JavaScript에서는 Math.floor(Date.now() / 1000)으로 초를 얻고, new Date(seconds * 1000)으로 되돌리세요.

윤초는 세지 않습니다

UTC는 지구 자전과 맞추기 위해 가끔 윤초를 넣으며, 1972년 이후 27번 추가되었습니다. 유닉스 시간은 이를 무시합니다. POSIX 공식은 모든 날을 86,400초로 가정하므로, 윤초는 시스템에 따라 반복되거나 더 긴 구간에 걸쳐 분산(smear)됩니다.

실제로는 두 타임스탬프를 빼서 얻은 경과 시간이 그 사이 윤초 수만큼 틀릴 수 있다는 뜻입니다. 일상적인 일정 관리에는 문제가 되지 않지만, 과학이나 금융 분야의 시간 측정에는 TAI나 GPS 시간을 씁니다. 국제 시간 관리 기구들은 2022년에 2035년까지 윤초 추가를 중단하기로 의결했습니다.

2038년 문제

오래된 소프트웨어는 유닉스 시간을 부호 있는 32비트 정수에 저장하며, 최댓값은 2147483647입니다. 이 값은 2038-01-19T03:14:07Z에 도달합니다. 1초 뒤 카운터가 오버플로해 -2147483648이 되고, 이는 1901-12-13T20:45:52Z로 읽힙니다.

• 최신 64비트 운영체제, 언어, 데이터베이스는 64비트 time_t를 쓰며, 약 2,920억 년 동안 버팁니다.
• 임베디드 기기, 오래된 파일 포맷, MySQL TIMESTAMP 같은 32비트 데이터베이스 칼럼, 시간에 4바이트만 할당한 바이너리 프로토콜에는 위험이 남아 있습니다.
• 20년짜리 인증서, 주택담보대출, 만료일처럼 먼 미래의 값은 이미 2038년을 넘으므로, 버그가 그보다 훨씬 일찍 나타날 수 있습니다.

타임스탬프와 날짜 문자열, 언제 무엇을 쓸까

이벤트 발생 시각이나 토큰 만료 시각 같은 순간은 유닉스 타임스탬프나 UTC 날짜 문자열로 저장하세요. 둘 다 모호하지 않고 올바르게 정렬됩니다.

사람이 읽을 로그, API, 파일에는 2026-10-14T09:30:00Z 같은 사람이 읽을 수 있는 ISO 8601 문자열을 쓰세요. 1791970200은 한눈에 아무 의미도 전하지 못하기 때문입니다. 내년 봄 파리에서 09:00에 열리는 회의처럼 미래의 현지 일정은 현지 시간과 IANA 시간대 이름으로 보관하세요. 그날이 오기 전에 서머타임 규칙이 바뀔 수 있고, 그러면 미리 계산한 타임스탬프가 틀리게 됩니다.