Unix 타임스탬프 변환기 — Epoch를 날짜로, 날짜를 Epoch로

Epoch 초, 밀리초, 마이크로초, 나노초를 원하는 시간대의 날짜로, 또 그 반대로 변환하세요. 실시간 시계, 일괄 모드, 코드 스니펫 제공.

현재 Unix 시간
초
—
밀리초
—

타임스탬프 → 날짜

초, 밀리초, 마이크로초, 나노초. 음수는 1970년 이전입니다.
해석 단위
초
UTC
Thu 2025-10-16 00:00:00.000 (UTC+00:00)
현지
UTC
ISO 8601 (UTC)
2025-10-16T00:00:00.000Z
ISO 8601 (UTC)
RFC 2822
상대 시간
초
1760572800
밀리초
1760572800000
마이크로초
1760572800000000
나노초
1760572800000000000

날짜 → 타임스탬프

YYYY-MM-DD HH:mm:ss는 오른쪽의 시간대로 해석합니다. Z나 오프셋이 있는 ISO 8601과 RFC 2822는 자체 시간대를 사용합니다.
Unix 초
1767225600
밀리초
1767225600000
ISO 8601 (UTC)
2026-01-01T00:00:00.000Z
UTC

일·주·월·년의 시작과 끝

UTC 기준, 주는 월요일에 시작 (ISO 8601)

일괄 변환

타임스탬프는 UTC 기준 ISO 8601로, 날짜는 Unix 초로 변환됩니다. 최대 5,000줄.
1700000000s
1760572800000ms
-1s
2038-01-19 03:14:07날짜
0s

코드로 현재 타임스탬프 가져오기

Math.floor(Date.now() / 1000)   // seconds
Date.now()                      // milliseconds

모든 작업이 브라우저에서 실행됩니다. 입력한 내용은 전송되거나 저장되지 않습니다. 모든 무료 도구 보기.

문제를 발견하셨거나 개선할 점이 있나요? 모든 메시지를 읽고 빠르게 고칩니다.

이 Unix 타임스탬프 변환기는 Epoch 값을 읽을 수 있는 날짜로, 날짜를 다시 Epoch 값으로 바꿔 줍니다. UTC, 내 시간대, 또는 브라우저가 아는 약 400개의 IANA 시간대 중 어느 것이든 쓸 수 있습니다. 로그 줄에서 가져온 1760572800, 1760572800000, 또는 19자리 나노초 값을 붙여 넣으세요. 단위는 자릿수로 감지되며, 값이 모호할 때는 직접 지정할 수 있습니다.

크고 특이한 값도 정확하게 처리합니다. 숫자를 BigInt로 구문 분석하므로 나노초 타임스탬프의 마지막 자릿수가 반올림되지 않고 유지되며, 1970년 이전의 음수 타임스탬프는 정확한 밀리초로 내림 처리되고, JavaScript 날짜 범위(약 기원전 271,821년 ~ 서기 275,760년)를 벗어난 값은 "Invalid Date"로 출력하는 대신 범위를 벗어났다고 알려 줍니다. 서머타임 변경을 포함한 시간대 오프셋은 브라우저 자체의 시간대 데이터를 사용합니다. 입력한 내용은 페이지 밖으로 나가지 않습니다.

사용 방법

  1. 첫 번째 칸에 타임스탬프를 붙여 넣으세요. 표에 UTC, 내 시간대, 선택한 시간대, ISO 8601, RFC 2822, 상대 시간이 표시됩니다.
  2. 단위가 틀렸다면(12자리 값은 서기 5138년 이후의 초일 수도, 1973년의 밀리초일 수도 있습니다) 단위 메뉴에서 고르세요.
  3. 반대로 변환하려면 날짜를 YYYY-MM-DD HH:mm:ss 형식으로 입력하고 그 날짜가 기준으로 하는 시간대를 고르세요. Z나 오프셋이 붙은 ISO 문자열은 그대로 읽습니다.
  4. "이번 달의 모든 데이터" 같은 범위 쿼리에는 시작/끝 표를, CSV나 로그에서 가져온 값 목록에는 일괄 변환 상자를 사용하세요.
  5. 각 값의 버튼으로 복사하거나, 사용하는 언어의 스니펫을 복사해 코드에서 현재 타임스탬프를 구하세요.

자주 묻는 질문

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

Unix 타임스탬프(Epoch 시간)는 1970년 1월 1일 00:00:00 UTC 이후 경과한 초의 수이며, 윤초는 세지 않습니다. 시간대가 없으므로 같은 순간은 어디서나 같은 타임스탬프를 가지며, 그래서 데이터베이스와 API가 이를 사용합니다. 많은 시스템은 대신 밀리초를 저장하고(JavaScript의 Date.now(), Java의 currentTimeMillis), 일부는 마이크로초나 나노초를 저장합니다.

타임스탬프가 초 단위인지 밀리초 단위인지 어떻게 알 수 있나요?

자릿수를 세세요. 현재 시점의 타임스탬프는 초 단위면 10자리, 밀리초면 13자리, 마이크로초면 16자리, 나노초면 19자리입니다. 이 도구는 그 경계를 자동으로 사용합니다. 유일하게 모호한 범위는 11~12자리로, 먼 미래의 초이거나 1970년대 초반의 밀리초입니다. 이 경우에는 단위를 직접 고르세요.

2038년 문제란 무엇인가요?

Unix 시간을 부호 있는 32비트 정수로 저장하는 시스템은 2,147,483,647까지만 셀 수 있으며, 이는 2038년 1월 19일 03:14:07 UTC입니다. 1초 뒤 값이 음수로 넘어가 1901년 12월로 읽힙니다. 최신 운영체제, 언어, 데이터베이스는 64비트 시간을 쓰지만, 오래된 임베디드 기기, 파일 형식, 32비트 INT로 선언된 데이터베이스 열에는 여전히 이 문제가 있습니다.

Unix 타임스탬프에 윤초가 포함되나요?

아니요. Unix 시간은 모든 하루를 정확히 86,400초로 취급하므로 윤초는 세지 않으며, 윤초가 생기면 타임스탬프가 1초 동안 반복되거나 멈춥니다. 덕분에 날짜 계산이 단순해지는 대신, 누적된 윤초(현재 37초)만큼 원자시(TAI)와 차이가 납니다. 거의 모든 애플리케이션 작업에서는 문제가 되지 않습니다.

Unix 타임스탬프가 음수일 수 있나요?

네. 음수 값은 1970년부터 거꾸로 셉니다. -1은 1969년 12월 31일 23:59:59 UTC이고, -86400은 그날의 시작입니다. 대부분의 언어는 음수 타임스탬프를 올바르게 처리하지만 일부 오래된 API와 스프레드시트 함수는 거부하므로, 생년월일이나 과거 날짜를 Epoch 값으로 저장하기 전에 확인하세요.

변환한 시간이 몇 시간 어긋나 보이는 이유는 무엇인가요?

거의 항상 시간대 혼동 때문입니다. 타임스탬프는 맞지만 현지 시간을 기대했는데 UTC로 표시되었거나, 현지 날짜 문자열이 UTC로 해석된 경우입니다. 타임스탬프 자체에는 시간대가 없습니다. 여기서는 시간대 선택기를 확인하고, 코드에서는 오프셋이 없는 날짜 문자열이 의도한 시간대로 해석되는지 확인하세요.

초, 밀리초, 마이크로초, 나노초: 누가 무엇을 쓰나

• 초(10자리): Unix와 POSIX time(), PHP time(), Python int(time.time()), PostgreSQL EXTRACT(EPOCH), JWT exp/iat/nbf 클레임, 대부분의 HTTP API.

• 밀리초(13자리): JavaScript Date.now(), Java System.currentTimeMillis(), Elasticsearch와 많은 JSON API, Kafka 레코드 타임스탬프.

• 마이크로초(16자리): PostgreSQL 내부 타임스탬프 저장, Python datetime 정밀도, Google BigQuery TIMESTAMP_MICROS.

• 나노초(19자리): Go time.UnixNano(), Python time.time_ns(), InfluxDB와 Prometheus remote-write, Linux clock_gettime. JavaScript 숫자로는 이 값을 정확히 담을 수 없기 때문에 이 도구는 BigInt로 구문 분석합니다.

두 시스템의 값이 1,000배 차이 난다면 하나는 초, 다른 하나는 밀리초입니다. 이 실수 하나가 "날짜가 1970년으로 나옴"과 "날짜가 5만 년으로 나옴" 버그의 대부분을 차지합니다.

시간대와 서머타임: 무엇이 잘못될 수 있나

타임스탬프를 현지 시간으로 바꾸는 것은 항상 명확합니다. 한 순간은 각 시간대에서 하나의 시계 시각에 대응합니다. 반대 방향은 그렇지 않습니다. 시계를 앞당기는 날에는 02:30 같은 현지 시각이 아예 존재하지 않고, 시계를 되돌리는 날에는 01:30이 두 번 있습니다.

이 변환기는 JavaScript Temporal API의 기본값과 같은 규칙을 따릅니다. 건너뛴 시각은 변경 전 오프셋으로 읽고(그래서 02:30은 서머타임 03:30이 됨), 반복되는 시각은 첫 번째로 해석합니다. 내 코드가 다른 규칙을 쓴다면 매년 그 두 날짜 즈음에 결과가 한 시간 차이 날 수 있습니다.

가장 안전한 방법은 순간을 UTC 타임스탬프나 오프셋을 명시한 ISO 8601 문자열로 저장하고 전송하며, 표시할 때만 현지 시간으로 변환하는 것입니다. 이때 -05:00 같은 고정 오프셋은 1년의 절반 동안 틀리므로 America/Toronto 같은 IANA 시간대 이름을 쓰세요.

ISO 8601 vs RFC 2822 vs Unix 시간

ISO 8601(2026-10-16T08:00:00Z 또는 2026-10-16T04:00:00-04:00)은 텍스트로 정렬해도 올바르게 정렬되고, 모호하지 않으며, JSON API, HTML datetime 속성, 대부분의 데이터베이스가 기대하는 형식입니다. 사람이 값을 읽을 가능성이 있다면 언제나 이 형식을 쓰세요.

RFC 2822(Fri, 16 Oct 2026 08:00:00 +0000)는 이메일과 HTTP 헤더 형식입니다. 읽기는 쉽지만 텍스트로 정렬되지 않으며, 1900년 이후의 연도에 대해서만 정의되어 있습니다.

Unix 타임스탬프는 가장 간결하고 비교가 가장 빠르지만, 변환기 없이는 읽을 수 없고 단위에 대한 단서도 없습니다. 합리적인 규칙은 이렇습니다. 시스템 내부에서는 Unix 시간, 시스템 경계에서는 ISO 8601.

관련 무료 도구

  • Cron 표현식 생성기 — 드롭다운으로 cron 일정을 만들거나 붙여 넣어 쉬운 말로 읽고, 다음 실행 10회를 내 시간대와 UTC로 확인하세요. 무료, 브라우저에서 실행.
  • JWT 디코더 — JWT의 헤더와 페이로드를 디코딩하고, 만료 시간을 알기 쉽게 확인하고, HS·RS·PS·ES 서명을 검증하거나 새 토큰에 서명하세요. 브라우저 밖으로 나가는 것은 없습니다.
  • UUID 생성기 — UUID v4나 시간순 v7, ULID, NanoID를 대량으로 생성하거나, ID를 붙여 넣어 버전과 포함된 타임스탬프를 확인하세요.
  • 진법 변환기 — 크기에 상관없이 정수를 2진수, 8진수, 10진수, 16진수, 32진법, 36진법 및 2~36 사이 모든 진법으로 변환하고 2의 보수도 확인하세요.