Unix Timestamp 변환기

Unix Timestamp 변환기는 컴퓨터에서 사용하는 시간 표현 방식인 Unix 타임스탬프(Epoch 시간)와 사람이 읽을 수 있는 날짜/시간 형식을 상호 변환하는 도구입니다. Unix 타임스탬프는 1970년 1월 1일 00:00:00 UTC부터 경과한 초(또는 밀리초)를 숫자로 표현한 것으로, 시간대에 독립적이고 계산이 간편하여 프로그래밍, 데이터베이스, API 통신에서 널리 사용됩니다. 서버 로그 분석, API 디버깅, 데이터 마이그레이션 등 개발 과정에서 시간 데이터를 다룰 때 필수적인 도구입니다.

사용 방법

1. 페이지 상단의 현재 시간 카드에서 지금 이 순간의 타임스탬프를 초/밀리초 단위로 실시간 확인할 수 있습니다. 각 값 옆의 복사 아이콘을 누르면 바로 클립보드에 담깁니다.
2. 타임스탬프 → 날짜 영역에 숫자를 입력하고 단위를 선택합니다. 기본값인 자동은 자릿수를 보고 초(10자리)인지 밀리초(13자리)인지 스스로 판별하며, 필요하면 초나 밀리초를 직접 지정할 수 있습니다.
3. 변환 버튼을 누르면 ISO 8601, UTC, 로컬 시간, 상대 시간("3시간 전" 같은 표현) 네 가지 형식으로 결과가 표시됩니다.
4. 현재, 0 (1970-01-01), 1B, 2B 퀵 버튼을 누르면 자주 참조하는 값을 입력 없이 바로 변환할 수 있습니다.
5. 반대 방향은 날짜 → 타임스탬프 영역에서 년·월·일·시·분·초를 채우고 시간대(로컬 시간대 또는 UTC)를 고른 뒤 변환을 누르면 초와 밀리초 값이 동시에 나옵니다.

개발자가 자주 빠지는 시간 함정

초와 밀리초 혼동. 가장 흔한 버그입니다. JavaScript의 Date 생성자는 밀리초를 기대하므로, 서버가 초 단위로 준 값을 그대로 넣으면 new Date(1704067200)은 2024년이 아니라 1970년 1월 20일이 되어 버립니다. new Date(1704067200 * 1000)처럼 1000을 곱해야 합니다. 반대로 밀리초 값을 초 단위만 받는 서버 API에 보내면 수만 년 뒤의 미래로 저장되는 사고가 납니다. 화면에 1970년 근처의 이상한 날짜가 보인다면 십중팔구 단위 혼동입니다.

시간대 누락으로 9시간 어긋나기. 타임스탬프 자체는 항상 UTC 기준이지만, 사람이 읽는 날짜로 바꾸는 순간 시간대가 개입합니다. DB에는 UTC로 저장하고 화면에서만 로컬로 변환하는 것이 정석인데, 이 변환을 빼먹으면 한국(KST, UTC+9)에서는 정확히 9시간 차이가 납니다. 표시되는 시간이 일정하게 9시간 어긋난다면 시간대 변환 누락부터 의심해 보세요. 이 도구가 UTC와 로컬 시간을 나란히 보여주는 것도 이 차이를 한눈에 확인하기 위해서입니다.

날짜 문자열 파싱의 함정. JavaScript에서 new Date("2026-07-02")는 UTC 자정으로 해석되어 한국 시간으로는 오전 9시가 되지만, new Date(2026, 6, 2)는 로컬 자정이 됩니다(월은 0부터 시작하는 것도 함정입니다). 같은 날짜라도 만들어지는 타임스탬프가 다르므로, 예상값을 이 변환기로 계산해 두고 코드 결과와 대조하면 원인을 빨리 찾을 수 있습니다.

자주 묻는 질문

자동 단위 감지는 어떤 기준으로 동작하나요?

자릿수를 기준으로 판별합니다. 현재 시점의 초 단위 타임스탬프는 10자리(예: 1704067200), 밀리초 단위는 13자리(예: 1704067200000)이므로 입력 길이만으로 대부분 정확히 구분됩니다. 아주 오래된 과거나 먼 미래의 값처럼 애매한 경우에는 단위를 직접 지정하세요.

기준이 왜 하필 1970년 1월 1일인가요?

1970년대 초 Unix 운영체제를 개발하면서 편의상 정한 기준점으로, 이를 Unix Epoch라고 부릅니다. 이후 거의 모든 운영체제와 프로그래밍 언어가 이 관례를 따르면서 사실상의 표준이 되었습니다.

음수 타임스탬프도 변환할 수 있나요?

네. 음수는 1970년 이전의 시각을 의미합니다. 예를 들어 -86400은 1969년 12월 31일 00:00:00 UTC입니다. 다만 일부 시스템이나 데이터베이스는 음수 타임스탬프를 지원하지 않으므로 과거 날짜를 다룰 때는 저장 대상의 지원 여부를 확인해야 합니다.

윤초는 반영되나요?

아니요. Unix 타임스탬프는 하루를 정확히 86,400초로 간주하고 윤초를 무시합니다. 일반적인 웹 개발에서는 문제가 되지 않지만, 정밀한 시각 동기화가 필요한 시스템은 NTP 같은 별도 프로토콜로 보정합니다.

밀리초보다 정밀한 값은 어떻게 다루나요?

일부 시스템은 마이크로초(16자리)나 나노초(19자리) 타임스탬프를 사용합니다. 이 도구는 밀리초까지 지원하므로, 나노초 값이라면 뒤 6자리를 잘라내고(1,000,000으로 나누고) 입력하면 밀리초로 변환할 수 있습니다.

결과에 나오는 ISO 8601은 어떤 형식인가요?

2026-07-02T09:30:00.000Z처럼 날짜와 시간을 T로 잇고 끝에 시간대 정보를 붙이는 국제 표준 표기법입니다. 끝의 Z는 UTC를 뜻하며, +09:00처럼 오프셋으로 표기할 수도 있습니다. 문자열 정렬만으로 시간순 정렬이 되고 시간대 정보를 함께 담을 수 있어 API 응답과 로그에서 가장 널리 쓰입니다.

언어별로 현재 타임스탬프를 얻는 방법이 궁금해요.

JavaScript는 Date.now()(밀리초), Python은 time.time()(초, 소수점 포함), PHP는 time()(초), Java는 System.currentTimeMillis()(밀리초)를 사용합니다. 언어마다 기본 단위가 다르다는 점이 앞서 설명한 초/밀리초 혼동 버그의 근본 원인이므로, 시스템을 넘나들 때는 단위를 명시적으로 맞춰야 합니다.

입력한 값이 서버로 전송되나요?

아니요. 모든 변환은 브라우저의 Date 객체로 기기 안에서만 계산되며 어떤 데이터도 외부로 나가지 않습니다. 사내 서버 로그에서 복사해 온 타임스탬프를 붙여넣어도 그 값이 어디에 저장되거나 전송되지 않습니다.

간단한 팁

결과를 그대로 코드에 붙여 넣기 전에 한 번 더 확인하는 습관을 들이면 실수를 줄일 수 있습니다. 특히 타임스탬프 변환기 같은 변환 도구는 양방향 변환이 가능한 경우가 많아, 원본으로 되돌려 보면서 검증하는 게 안전합니다.