타임스탬프 변환기
Unix 타임스탬프(초/밀리초)와 ISO 8601 / 일본시간 / UTC를 상호 변환. 로그 분석, API 디버깅, 데이터 마이그레이션 시 날짜 확인에 활용.
| Unix(초) | |
|---|---|
| Unix(밀리초) | |
| ISO 8601 (UTC) | |
| ISO 8601 (JST) | |
| JST(일본 시간) | |
| UTC | |
| RFC 2822 | |
| 요일(JST) | |
| 상대 시간 |
복사되었습니다
📖 자주 걸리는 지점
Unix 타임스탬프(초 / 밀리초)와 ISO 8601 / JST / UTC 를 상호 변환합니다. 초인지 밀리초인지는 자릿수로 추측합니다 — 13 자리 이상이면 밀리초, 10 자리면 초로 다룹니다. 이는 실무상 거의 들어맞는 경험칙이지 사양이 아닙니다. 타임스탬프라는 값 자체에는 단위도 타임존도 적혀 있지 않으므로 최종적인 판단은 그 값을 내놓은 시스템의 사양으로밖에 내릴 수 없습니다.
| 사례 | 무슨 일이 일어나는가 | 어떻게 하면 되는가 |
|---|---|---|
| 1970 년이나 5 만 년 뒤가 된다 | 초와 밀리초를 잘못 본 전형적인 증상입니다. 밀리초 값을 초로 읽으면 서기 55000 년 전후가 되고 초 값을 밀리초로 읽으면 1970 년 1 월 20 일 전후가 됩니다. 언어마다 기본 단위가 다른 것이 원인이며 JavaScript 의 Date.now() 와 Java 의 System.currentTimeMillis() 는 밀리초, PHP 의 time() · Python 의 time.time() · 셸의 date +%s 는 초입니다. JSON 을 거쳐 다른 언어로 넘기는 경계에서 반드시 일어납니다. |
자릿수를 세는 것이 가장 빠른 판별법입니다. 2001 년 9 월 9 일 이후 초는 10 자리(2286 년까지), 밀리초는 13 자리(2286 년까지) 이므로 당분간은 이 둘만 구분하면 충분합니다. 설계 쪽에서는 API 의 필드 이름에 단위를 넣어 버리는 것이 사고가 가장 적습니다 — expires_at 이 아니라 expires_at_ms 라고 쓰면 받는 쪽이 오해할 여지가 없습니다. 애초에 ISO 8601 문자열로 넘길 수 있다면 그편이 안전합니다(사람이 눈으로 읽을 수 있으므로 이런 종류의 실수가 코드 리뷰에서 멈춥니다). |
| 같은 날짜 문자열이 환경에 따라 다른 시각이 된다 | 타임존을 쓰지 않은 문자열은 해석이 구현에 달려 있습니다. JavaScript 에서는 2024-01-01(날짜만)은 UTC, 2024-01-01T00:00:00(시각 포함)은 로컬 시각으로 해석됩니다 — 한 글자 차이로 9 시간이 어긋납니다. 게다가 2024-01-01 09:00:00 같은 공백 구분은 ISO 8601 에서도 ECMAScript 에서도 규정 밖이라 브라우저마다 독자적인 해석이 됩니다. 서버가 UTC, 개발기가 JST 인 구성에서는 로컬에서는 제대로 도는데 프로덕션만 9 시간 어긋나는 형태로 드러납니다. |
타임존을 생략한 문자열을 쓰지 마세요. 반드시 Z 나 +09:00 을 붙입니다 — 2024-01-01T00:00:00Z 라면 어떤 구현에서도 같은 하나의 순간을 가리킵니다. 운용의 원칙은 저장은 UTC, 표시할 때만 로컬로 변환입니다. 데이터베이스의 열 타입에도 같은 함정이 있습니다 — MySQL 의 TIMESTAMP 는 세션의 타임존으로 변환되어 나오지만 DATETIME 은 쓴 문자열이 그대로 돌아옵니다. 서버 이전으로 time_zone 이 바뀌면 TIMESTAMP 열만 과거 데이터째 어긋나 보입니다. |
| 고정 오프셋으로 저장해 서머타임이나 법 개정으로 어긋난다 | +09:00 같은 오프셋은 그 순간의 차이이지 지역이 아닙니다. JST 는 서머타임이 없어 일본 국내만이라면 문제가 잘 생기지 않지만 미국이나 유럽 사용자를 다루는 순간 무너집니다 — 뉴욕은 -05:00 과 -04:00 을 연 2 회 오가므로 3 월에 -05:00 으로 저장한 매주 월요일 9 시 회의는 4 월에는 8 시에 울립니다. 오프셋은 법률로 바뀝니다 — 실제로 사모아는 2011 년에 날짜변경선을 넘어 12 월 30 일이라는 날이 존재하지 않는 해가 있었습니다. |
과거의 기록은 오프셋이 붙은 순간(UTC)으로, 미래의 예정은 IANA 타임존 이름 + 로컬 시각으로 저장하세요. 이 둘은 목적이 다릅니다 — 로그는 언제 일어났는가 이므로 순간으로 충분하지만 예정은 현지의 9 시 라는 약속이므로 Asia/Tokyo 나 America/New_York 라는 지역 이름으로 갖고 있지 않으면 법 개정 때마다 예정이 움직여 버립니다. 타임존 데이터베이스(tzdata)는 연 몇 차례 갱신됩니다 — 컨테이너 이미지를 고정해 두면 오래된 규칙 그대로 계속 돌기 때문에 베이스 이미지의 갱신은 보안 이외의 이유로도 필요하다고 기억해 두세요. |
Unix 타임스탬프는 1970-01-01T00:00:00Z 부터의 경과 초 수가 아닙니다 — 정확히는 윤초를 없었던 것으로 한 통산 초입니다. 실제 경과 초 수와는 2026 년 시점에 27 초 어긋나 있습니다. 일상적인 애플리케이션에서는 무시해도 되지만 금융 거래의 순서나 분산 시스템의 인과 관계를 다룬다면 이 1 초가 문제가 됩니다 — 윤초 삽입 시 시스템에 따라 같은 타임스탬프가 두 번 나오거나 시계가 1 초 되감깁니다. Google 이나 AWS 는 하루에 걸쳐 조금씩 시계를 늦추는 smear 방식을 채택하고 있어 그날은 다른 회사의 시계와 최대 0.5 초 어긋납니다. 시각의 유일성이 필요한 장면에서는 타임스탬프를 기본 키로 삼지 말고 단조 증가하는 ID 를 함께 쓰세요.
📖 사용법
-
1
타임스탬프 또는 날짜 문자열 입력입력란에 Unix 타임스탬프(초/밀리초) 또는 ISO 8601 날짜 문자열을 입력합니다.
-
2
변환 결과 확인여러 형식의 변환 결과가 표시됩니다. 각 행을 클릭하면 복사됩니다.
-
3
+1일/-1시간 등 버튼으로 조정+/-1일, +/-1시간 버튼으로 타임스탬프를 조정합니다.
❓ 자주 묻는 질문
초와 밀리초는 어떻게 구분하나요?
JST(일본 표준시)란?
Unix 타임스탬프란?
🐛 이 도구에서 문제가 발생했나요?
무료 · 가입 불필요. 재현 절차만이라도 도움이 됩니다. 보고는 운영자에게 직접 전달되어 개선에 사용됩니다.
보고 감사합니다!
운영자에게 전달되었습니다. 개선에 사용됩니다.