타임스탬프 변환기

Unix 타임스탬프에 대하여

Unix 타임스탬프는 1970년 1월 1일 UTC("에포크")부터 경과한 초(또는 밀리초)를 세는 값입니다. 타임존이나 달력 표기 형식과 무관하게 특정 순간을 명확하게 나타내는 단일 숫자이며, 이 때문에 대부분의 시스템은 내부적으로 날짜를 이 방식으로 저장하고 교환합니다.

Unix 시간은 윤초를 무시하는 것으로 유명합니다. 하루는 정확히 86,400초로 정의되어 있어서, 지구 자전에 시계를 맞추기 위한 드문 윤초는 세어지는 것이 아니라 그냥 흡수됩니다. 그래서 Unix 시간을 진정으로 선형적이라기보다 "거의 선형적"이라고 부르기도 합니다. 더 실질적인 한계도 있습니다. 전통적인 부호 있는 32비트 표현의 Unix 시간은 2038년 1월 19일에 오버플로우됩니다. 이른바 "2038년 문제"입니다. 다만 오늘날 대부분의 시스템은 타임스탬프를 64비트 값으로 저장하며, 이는 같은 오버플로우를 약 2,920억 년 뒤로 미룹니다.

사용되는 곳

• API 응답이나 데이터베이스 행에서 created_at 또는 expires_at 필드 읽기
• JWT의 exp나 iat 클레임이 예상과 다른 이유 디버깅
• 장애를 조사하는 동안 로그 타임스탬프를 로컬 시간으로 변환
• 캐시, 토큰, 세션이 실제로 만료되었는지 확인

자주 묻는 질문

타임스탬프가 초 단위인지 밀리초 단위인지 어떻게 알 수 있나요?
최근 날짜의 경우 초 단위 타임스탬프는 10자리, 밀리초 단위는 13자리입니다. 이 도구는 붙여넣은 값이 어느 쪽인지 자동으로 감지합니다.

타임스탬프가 몇 시간씩 "잘못된" 것처럼 보이는 이유는 무엇인가요?
Unix 타임스탬프 자체에는 타임존이 없습니다. 그것은 정확한 한 순간입니다. 바뀌는 것은 표시 방식뿐입니다. 여기 UTC와 로컬 행은 같은 순간을 서로 다른 두 타임존에 맞게 표시한 것입니다.

1970년 이전 날짜도 처리할 수 있나요?
예. 음수 타임스탬프는 에포크 이전의 순간을 나타내며, 이 도구는 동일한 방식으로 이를 해석하고 표시합니다.

2038년 문제란 무엇인가요?
전통적인 부호 있는 32비트 Unix 타임스탬프는 에포크 이후 2,147,483,647초까지만, 즉 2038년 1월 19일 03:14:07 UTC까지만 셀 수 있습니다. 그 1초 뒤에는 오버플로우되어 음수로 넘어가는데, 이는 흔히 1901년의 날짜로 읽힙니다. 아직 32비트 타임스탬프를 쓰는 시스템(일부 임베디드 기기와 오래된 32비트 소프트웨어)이 영향을 받습니다. 오늘날 대부분의 64비트 시스템은 이미 타임스탬프를 64비트로 저장하고 있어, 같은 오버플로우를 실용적인 시간 범위를 훨씬 넘어서까지 미룹니다.