유닉스 타임스탬프 변환기

유닉스 epoch 타임스탬프를 사람이 읽는 날짜로, 또 그 반대로 시간대별로 변환합니다. 로그를 읽는 동안 옆에 띄워 두는 용도입니다.

Unix 시간은 1970년 1월 1일 UTC부터의 초를 셉니다. 이와 얽힌 버그는 거의 셋 중 하나입니다. 밀리초 값을 초로 읽어 1970년으로 떨어지거나, 로컬 시각을 UTC로 취급하거나, 하루가 항상 86,400초라고 가정했는데 그 지역 달력에 서머타임 전환이 끼어 있는 경우입니다.

이 변환기는 같은 순간을 Unix 값, ISO 8601 문자열, UTC, 그리고 여러분의 로컬 시각으로 나란히 보여 줍니다. 어긋남을 추론하지 않고 눈으로 확인할 수 있습니다. 초 단위와 밀리초 단위는 자릿수로 구분하는데, 애초에 그 실수를 잡아내는 것과 같은 기준입니다.

2038년 문제는 지나간 이야기가 아닙니다. 부호 있는 32비트 초 카운터는 2038년 1월 19일 03:14:07 UTC에 한계에 이르고 1901년으로 돌아갑니다. 데스크톱과 서버 소프트웨어는 오래전에 64비트로 옮겨 갔지만, 잊기 쉬운 곳에는 여전히 그 한계가 박혀 있습니다. MySQL의 TIMESTAMP 컬럼은 1970년부터 2038년까지만 받고 그 바깥은 받지 않는 반면 DATETIME에는 그런 제한이 없으며, 32비트 시계를 쓰는 임베디드 펌웨어는 앞으로도 한동안 출하됩니다. 경계에 먼저 닿는 것은 먼 미래의 날짜입니다. 만료일, 대출 만기, 인증서 유효기간 같은 것들이고, 2038년이 오기 훨씬 전에 문제가 됩니다. 이 페이지에서 값이 1901년이나 1970년 근처로 변환된다면 오버플로 아니면 초와 밀리초를 혼동한 것이 거의 항상 원인입니다.

유닉스 시간은 흘러간 초를 세는 값이 아닙니다. 그렇다고 생각하는 사람이 걸려 넘어지는 지점입니다. POSIX에서 하루는 정확히 86,400초로 정의되므로 1972년 이후 UTC에 끼워 넣어진 윤초는 이 숫자에 아예 나타나지 않습니다. 그래서 윤초를 사이에 둔 두 유닉스 타임스탬프를 빼면 실제 물리적 간격보다 1초 짧은 값이 나오고, 그 남는 1초를 어떻게 처리할지도 시스템마다 다릅니다. 같은 값을 두 번 반복하는 곳이 있고, 하루에 걸쳐 시계를 느리게 돌려 흡수하는 곳이 있습니다. 일정을 잡거나 분 단위 시간을 재는 데는 아무 영향이 없습니다. 문제가 되는 것은 여러 해에 걸친 간격을 초 단위로 재는 경우인데, 하필 아무도 확인해 볼 생각을 하지 않는 경우이기도 합니다.

ISO 8601과 RFC 3339는 서로 바꿔 쓸 수 있는 것이 아니고, 그 차이는 멀쩡해 보이는 문자열을 파서가 거부하는 형태로 드러납니다. RFC 3339는 좁은 프로파일입니다. 날짜와 시각과 오프셋을 모두 갖춘 형태여야 하고, 2026-08-24T09:30:00+09:00 이거나 같은 시점을 UTC로 적은 Z 접미사 형태입니다. ISO 8601은 훨씬 넓어서 주 단위 날짜, 연중 일수 표기, 구분자를 뺀 축약형까지 허용하는데 대부분은 JSON API가 받아 주지 않습니다. 오프셋과 시간대를 구분해 두는 것도 중요합니다. +09:00 은 어느 한 순간에 시계가 가리킨 값을 기록한 것이고 Asia/Seoul 은 규칙을 기록한 것이라, 서머타임 전환이나 어느 나라의 오프셋 변경을 견디는 것은 뒤쪽뿐입니다.

1970년 이전 날짜는 음수 유닉스 타임스탬프이고, 지원 여부가 제각각이라 짐작하지 말고 시험해 보는 편이 낫습니다. 계산 자체는 잘 정의되어 있습니다. 1965년의 생년월일은 그냥 음수 초입니다. 다만 값이 부호 없는 수라고 전제하고 작성된 코드 경로가 적지 않고, 그런 코드는 2106년의 날짜를 내놓거나 입력을 거부하거나 0을 저장하는 식으로 반응합니다. 이 페이지는 음수 값도 정상적으로 변환하므로, 어떤 시스템에 뜬금없이 나타난 1970년이나 2106년이 저장 한계 때문인지 변환 버그 때문인지 빠르게 가려내는 데 쓸 수 있습니다.