Unix 타임스탬프 & 에폭 변환기 · 다중 정밀도

Unix 타임스탬프를 날짜로 즉시 변환합니다. 초, 밀리초, 마이크로초를 자동 감지하며 실시간 시계와 양방향 변환을 온라인에서 무료로 제공합니다.

트래킹 없음 브라우저 실행 무료

모든 처리는 브라우저 안에서 이루어집니다. 어떤 서버로도 데이터가 전송되지 않습니다.

현재 Unix 타임스탬프

Unix 타임스탬프

빠른 참고

코드 예시

POSIX 준수와 정밀도 정확성을 검토했습니다 — Go Tools 엔지니어링 팀 · Mar 22, 2026

Unix 타임스탬프(에폭 시간)란 무엇인가요?

Unix 타임스탬프(에폭 시간 또는 POSIX 시간이라고도 부름)는 1970년 1월 1일 00:00:00 UTC 이후로 경과한 초 수이며, 사실상 모든 컴퓨팅 시스템의 보편적 시간 기준으로 사용됩니다. Linux 커널과 SQL 데이터베이스, JavaScript 엔진, 모바일 운영체제에 이르기까지 거의 모든 현대 플랫폼이 시간을 Unix 타임스탬프로 저장하고 교환합니다.

IEEE Std 1003.1 (POSIX)가 공식적으로 정의하듯이 "Unix 에폭(1970년 1월 1일 00:00:00 UTC)은 POSIX 시간의 영점 역할을 합니다". 이는 너무나 보편적으로 채택되어 지금은 전 세계 기계 판독 가능 타임스탬프의 사실상 표준입니다. Unix 타임스탬프는 HTTP 헤더, JWT 토큰, 거의 모든 REST API를 포함해 압도적 다수의 서버 측 시스템, 데이터베이스, 네트워크 프로토콜에서 사용됩니다.

Unix 에폭 자체 · 1970년 1월 1일은 임의로 선택된 값이 아닙니다. Unix는 1960년대 후반 벨 연구소에서 개발되었고, 1970년은 당시 모든 관련 날짜를 감당 가능한 정수 크기로 표현할 수 있을 만큼 최근이면서 편리하고 딱 떨어지는 시작점이었습니다. 어떤 시점도 해당 기준점으로부터의 부호 있는 64비트 정수 초 수로 표현할 수 있습니다. 에폭 이전 날짜는 음수로 표현됩니다. 1969년 12월 31일 UTC 자정은 -86400(에폭 1일 또는 86,400초 이전)입니다.

현대 시스템은 종종 초 단위보다 더 세밀한 시간 해상도를 필요로 합니다. 이를 위해 타임스탬프는 일반적으로 밀리초(1,000분의 1초 · JavaScript의 `Date.now()`나 Java의 `System.currentTimeMillis()`가 반환)나 마이크로초(100만분의 1초 · PostgreSQL 같은 데이터베이스와 고빈도 거래 시스템에서 사용)로 표시됩니다. 자릿수로 정밀도를 식별할 수 있습니다. 10자리는 초, 13자리는 밀리초, 16자리는 마이크로초를 나타냅니다. 본 변환기는 입력의 정밀도를 자동으로 감지합니다.

Unix 타임스탬프는 분산 컴퓨팅의 근간입니다. 시간대에 독립적이고 정상 조건에서 단조 증가하며 정수로 간단히 정렬할 수 있기 때문입니다. 시간을 타임스탬프로 저장하고 표시 시점에만 사람이 읽기 쉬운 형식으로 변환하는 것이 시간대 버그를 통째로 제거하는 모범 사례입니다. 단점은 가독성입니다. 1741965432 같은 원시 타임스탬프는 변환기 없이는 알아볼 수 없는데, 바로 이를 본 도구가 제공합니다.

모든 변환은 JavaScript Date API를 사용해 브라우저 안에서 완전히 이루어집니다. 타임스탬프, 날짜 등 어떤 데이터도 서버로 전송되지 않습니다. 본 도구는 위 실시간 시계에 표시되는 현재 에폭 시간을 포함한 모든 Unix 타임스탬프를 완전한 프라이버시 아래 사람이 읽기 쉬운 날짜로 즉시 변환합니다.

타임스탬프는 다른 개발자 도구와 밀접한 관련이 있습니다. UUID v1과 v7은 식별자 안에 타임스탬프를 직접 내장하며, 타임스탬프가 포함된 API 응답은 가독성을 위해 JSON 포매터로 점검하는 것이 가장 편리한 경우가 많습니다. 정밀도, 시간대 처리, DST 함정을 JavaScript, Python, Go 코드 예시와 함께 다룬 심층 가이드는 Unix 타임스탬프 가이드를 참고하십시오.

// Get the current Unix timestamp in JavaScript
const timestampSeconds = Math.floor(Date.now() / 1000);
console.log(timestampSeconds); // → 1741965432

// Milliseconds (native JavaScript)
const timestampMs = Date.now();
console.log(timestampMs); // → 1741965432000

// Convert timestamp back to a Date object
const date = new Date(timestampSeconds * 1000);
console.log(date.toISOString()); // → '2025-03-14T15:37:12.000Z'

// Python equivalent
// import time
// timestamp = int(time.time())  # → 1741965432

주요 기능

자동 정밀도 감지

타임스탬프가 초(10자리), 밀리초(13자리), 마이크로초(16자리) 중 무엇인지 자동으로 감지합니다. 수동으로 모드를 전환할 필요가 없습니다.

양방향 변환

타임스탬프를 사람이 읽기 쉬운 날짜로 변환하거나, 날짜와 시간을 선택해 해당하는 Unix 타임스탬프를 세 가지 정밀도 형식으로 즉시 얻을 수 있습니다.

실시간 에폭 시계

현재 Unix 타임스탬프가 실시간으로 째깍이는 모습을 볼 수 있어 변환과 계산에 언제나 정확한 기준점을 제공합니다.

다중 형식 출력

모든 변환은 UTC 시간, 로컬 시간대, ISO 8601 형식, 사람이 읽기 쉬운 상대 시간(예: "3일 전")을 동시에 출력합니다.

100% 브라우저 측 처리

모든 변환은 JavaScript Date API를 사용해 브라우저 안에서 완전히 이루어집니다. 타임스탬프, 날짜, 개인 데이터가 어떤 서버로도 전송되지 않습니다.

Unix 타임스탬프 vs 다른 날짜 형식

ISO 8601

2025-03-14T15:37:12Z

사람이 읽기 쉽고 사전식으로 정렬 가능합니다. 데이터 교환과 API의 표준입니다. 가독성이 중요할 때 Unix 타임스탬프보다 선호됩니다.

RFC 2822

Fri, 14 Mar 2025 15:37:12 +0000

사람이 읽기는 쉽지만 정렬 가능하지 않습니다. 주로 이메일 헤더(Date 필드)에 쓰입니다. ISO 8601과 Unix 타임스탬프보다 덜 압축적입니다.

사람이 읽는 날짜

2025년 3월 14일 오후 3:37

최종 사용자에게 가장 읽기 쉬운 형식이지만 정렬 가능하지도, 프로그래밍 용도로 적합하지도 않습니다. UI 표시 계층에만 사용하십시오.

변환 예시

표준 Unix 타임스탬프 (초)

1741965432

2025-03-14T15:37:12Z

초 단위 10자리 타임스탬프. Unix/Linux 시스템, Unix API, JWT 토큰, 서버 로그에서 가장 흔히 쓰이는 형식입니다. 이 값은 2025년 파이 데이 15:37:12 UTC에 해당합니다.

Y2K 타임스탬프 · 2000년 1월 1일

946684800

2000-01-01T00:00:00Z

Y2K 순간의 Unix 타임스탬프. Unix 에폭으로부터 정확히 946,684,800초 뒤입니다. 유용한 보정값입니다. 이 입력에 대해 변환기가 2000년 1월 1일을 출력하면 제대로 동작한다는 뜻입니다.

음의 타임스탬프 (에폭 이전)

-86400

1969-12-31T00:00:00Z

음의 Unix 타임스탬프는 1970년 1월 1일 이전 날짜를 나타냅니다. -86400은 에폭보다 정확히 1일(86,400초) 전이며 이는 1969년 12월 31일 UTC 자정에 해당합니다. 모든 시스템이 음의 타임스탬프를 지원하지는 않지만 본 변환기는 이를 올바르게 처리합니다.

밀리초 타임스탬프 (13자리)

1741965432000

2025-03-14T15:37:12.000Z

밀리초 단위 13자리 타임스탬프. JavaScript의 Date.now(), Java의 System.currentTimeMillis(), 대부분의 현대 REST API가 기본으로 쓰는 형식입니다. 첫 번째 예시를 1000으로 곱한 값과 같습니다. 자동 감지기는 13자리 길이를 인식해 밀리초로 올바르게 해석합니다.

Unix 타임스탬프를 날짜로 변환하는 방법

1

변환 방향 선택

"타임스탬프 → 날짜"를 선택해 Unix 타임스탬프를 사람이 읽기 쉬운 날짜로 해석하거나, "날짜 → 타임스탬프"를 선택해 달력 날짜와 시간을 Unix 타임스탬프로 변환하십시오.
2

값 입력

입력란에 Unix 타임스탬프(예: 1741965432 또는 1741965432000)를 붙여넣거나 타이핑하십시오. 본 도구는 그것이 초인지, 밀리초인지, 마이크로초인지 자동으로 식별합니다. 날짜 → 타임스탬프의 경우 날짜 선택기로 연, 월, 일, 시, 분, 초를 선택하십시오.
3

변환 결과 복사

UTC, 로컬 시간, ISO 8601, 상대 시간으로 결과를 즉시 확인하십시오. 각 형식 옆의 복사 버튼을 누르면 클립보드로 바로 복사됩니다.

일반 활용 사례

API 개발과 디버깅: API 응답, JWT 토큰 페이로드(iat, exp, nbf 클레임), 웹훅 이벤트 데이터, 로그 항목의 불투명한 타임스탬프를 해석합니다. 인증 토큰이 만료되었는지 또는 이벤트가 언제 발생했는지 즉시 확인할 수 있습니다.
데이터베이스 타임스탬프 저장과 질의: 데이터베이스 질의를 작성하거나 저장된 레코드를 점검하거나 WHERE 절의 날짜 범위 필터가 올바르게 지정되었는지 검증할 때 Unix 타임스탬프와 사람이 읽기 쉬운 날짜 사이를 변환합니다.
로그 파일 분석과 상관 관계: 많은 시스템과 애플리케이션 로그가 이벤트를 Unix 타임스탬프로 기록합니다. 의심스러운 로그 항목을 사람이 읽기 쉬운 시간으로 변환해 여러 서비스에 걸친 이벤트를 상관시키고 공격 시점을 식별하며 오류 발생 정확한 순간을 집어냅니다.
JWT 토큰 만료 검증: JSON Web Token은 iat(발급 시각), exp(만료 시각), nbf(유효 시작 시각)를 페이로드에 Unix 타임스탬프로 인코딩합니다. 이 값을 직접 붙여 에폭 계산을 수동으로 하지 않고 토큰 유효 구간을 확인하십시오.
cron 작업 예약: 제안된 실행 시각을 타임스탬프로 변환하고 되돌려 확인함으로써 cron 작업 스케줄, 예약 작업, 시간 기반 트리거가 의도된 실행 구간에 맞는지 검증합니다.
교차 시간대 날짜 조정: Unix 타임스탬프는 본질적으로 시간대 중립입니다. 서로 다른 시간대의 팀 간에 날짜와 마감일을 조율할 때 공유 기준점을 세우고 어떤 로컬 시간의 UTC 등가를 확인하십시오.

기술 참조

Unix 타임스탬프 정의: Unix 타임스탬프는 Unix 에폭(1970년 1월 1일 00:00:00 UTC · 협정 세계시) 이후 경과한 초 수를 나타내는 정수입니다. 이 값은 관찰자의 로컬 시간대와 무관하게 동일하므로 시간을 저장하고 비교할 때 시간대 중립적인 표현으로 이상적입니다.
32비트 부호 있는 정수 최대값: 부호 있는 32비트 정수의 최대값은 2,147,483,647입니다. Unix 타임스탬프로 해석하면 이는 2038년 1월 19일 03:14:07 UTC에 해당합니다. 타임스탬프를 32비트 부호 있는 정수로 저장하는 시스템은 이 시점에 오버플로를 일으킵니다. Y2038 문제로 알려진 현상입니다. 64비트 시스템은 수십억 년 뒤의 날짜도 표현할 수 있습니다.
JavaScript는 밀리초를 사용: JavaScript의 Date.now()와 new Date().getTime()은 초가 아니라 에폭 이후 밀리초 수를 반환합니다. 이는 13자리 숫자를 만듭니다. 표준 Unix 초 타임스탬프로 변환하려면 1000으로 나누고 내림하십시오. Math.floor(Date.now() / 1000). 많은 API와 도구가 초를 기대하므로 이 변환 단계가 중요합니다.
음의 타임스탬프는 에폭 이전 날짜: Unix 타임스탬프는 1970년 1월 1일 이전 날짜를 나타내기 위해 음수가 될 수 있습니다. 예를 들어 -86400은 1969년 12월 31일 00:00:00 UTC를 나타냅니다. 부호 있는 64비트 타임스탬프의 범위는 에폭 이전 약 2920억 년부터 이후 2920억 년까지로 어떤 실용적 응용에도 충분합니다.
Unix 시간은 윤초를 고려하지 않음: Unix 시간은 하루를 정확히 86,400초(24시간 × 60분 × 60초)로 가정합니다. 실제로는 지구 자전과 UTC 동기화를 위해 IERS가 윤초를 때때로 삽입합니다. 즉 Unix 시간은 TAI(국제 원자시)와 완벽히 선형이 아니며 차이는 시간이 지나며 벌어집니다. 대부분의 응용에서 이 불일치는 무관하지만, 정밀 시간 측정 시스템은 이를 반드시 고려해야 합니다.

타임스탬프 처리 모범 사례

타임스탬프는 항상 UTC로 저장: 타임스탬프는 UTC(또는 Unix 타임스탬프)로 저장하고 표시 계층에서만 로컬 시간으로 변환하십시오. 데이터베이스에 시간대를 섞어 두는 것은 재현과 디버깅이 어려운 버그의 흔한 원인이며 특히 일광 절약 시간 전환에서 문제가 됩니다.
현대 API에는 밀리초 정밀도 사용: 대부분의 현대 API, JavaScript 환경, 데이터베이스는 초(10자리 타임스탬프)가 아니라 밀리초(13자리 타임스탬프)를 사용합니다. 외부 시스템과 통합할 때는 기대하는 정밀도를 확인하십시오. 초가 예상되는 곳에 밀리초 타임스탬프를 넘기면 약 11,000년 뒤의 날짜가 나옵니다.
Y2038 문제 주의: 타임스탬프를 32비트 부호 있는 정수로 저장하는 시스템은 2038년 1월 19일 03:14:07 UTC에 오버플로를 일으킵니다. 레거시 시스템의 32비트 타임스탬프 필드를 감사하고 64비트 정수나 ISO 8601 문자열로 이전하십시오. 대부분의 현대 언어와 데이터베이스는 기본적으로 64비트 타임스탬프를 쓰지만 임베디드 시스템, 오래된 데이터베이스, 파일 시스템은 여전히 위험할 수 있습니다.
보안에는 절대 클라이언트 시계에 의존하지 마십시오: 클라이언트 장치 시계는 의도든 악의든 어떤 값으로도 설정될 수 있습니다. JWT 만료 검사, 세션 타임아웃, 속도 제한 같은 보안 민감 로직에는 절대로 클라이언트가 제공한 타임스탬프를 사용하지 마십시오. 항상 신뢰할 수 있는 시간 출처를 사용해 서버에서 타임스탬프를 검증하십시오.
사람이 읽기 쉬운 교환에는 ISO 8601 사용: 기계 판독 가능성과 가독성이 모두 필요한 타임스탬프 형식이 필요할 때 · 예를 들어 로그 파일, 구성 파일, 개발자가 읽을 수 있는 API 응답 · ISO 8601(예: 2025-03-14T15:37:12Z)이 최선입니다. 사전식으로 정렬 가능하고 모호하지 않으며 사실상 모든 현대 파서가 지원합니다.

자주 묻는 질문

Unix 시간은 왜 1970년 1월 1일부터 시작하나요?

Unix 에폭 날짜 1970년 1월 1일은 1960년대 후반 벨 연구소의 Unix 개발자들이 최근이면서 계산상 실용적인 편리한 반올림 시작점으로 선택했습니다. 당시 타임스탬프는 32비트 정수에 저장되었으므로 에폭은 일반적인 날짜가 적당한 크기의 숫자에 들어갈 만큼 현재에 가까워야 했습니다. 1970년은 시스템 개발이 시작된 시점 이후의 깔끔한 반올림 연도였을 뿐입니다. 1970년 1월 1일 자체에 깊은 기술적 의미는 없습니다. 공학적 실용주의였습니다. 다른 시스템은 다른 에폭을 택했습니다. Macintosh 클래식 툴박스는 1904년 1월 1일을 썼고, Windows NT는 1601년 1월 1일을, GPS 시간은 1980년 1월 6일을 시작점으로 삼습니다. 각각 채택한 시스템의 시대와 설계 제약을 반영합니다. Unix 에폭이 정착한 것은 Unix가 컴퓨팅의 지배적인 운영체제가 되었고, 모든 주요 프로그래밍 언어, 데이터베이스, 운영체제가 결국 기계 판독 가능 타임스탬프를 나타내는 보편 표준으로 Unix 시간을 채택했기 때문입니다. 오늘날 Unix 에폭은 Linux 커널부터 JavaScript 엔진, SQL 데이터베이스에 이르기까지 모든 주요 플랫폼이 인식하는 사실상 보편 상수입니다. 이 선택에는 잘 알려진 결과가 하나 있습니다. 1970년 1월 1일 이전 날짜는 음수로 표현되며 일부 오래된 시스템은 이를 다루지 못합니다. 역사적 날짜와 천문 계산에는 대체 타임스탬프 형식이 선호되기도 합니다. 다만 압도적 다수의 소프트웨어 개발에는 Unix 에폭이 모든 관련 날짜를 넉넉히 담아냅니다.

Y2038 문제는 무엇인가요?

Y2038 문제(Y2K38 또는 에포컬립스라고도 함)는 Unix 타임스탬프를 부호 있는 32비트 정수로 저장하는 시스템에 영향을 미칠 컴퓨팅 이슈입니다. 부호 있는 32비트 정수는 -2,147,483,648부터 2,147,483,647까지의 값을 가질 수 있습니다. Unix 타임스탬프로 해석할 때 최대값 2,147,483,647은 2038년 1월 19일 03:14:07 UTC에 해당합니다. 한 번 1초가 더 흐르면 카운터가 오버플로되어 표현 가능한 가장 작은 음수 값으로 감싸지며, 이는 1901년 12월 13일에 해당합니다. 이 시스템은 미래 날짜를 먼 과거로 해석하게 됩니다. 타임스탬프를 어떻게 쓰느냐에 따라 결과는 사소한 것부터 치명적인 것까지 다양합니다. 시스템이 입력 검증에서 유효한 미래 날짜를 거부하거나, 시간 민감 레코드를 잘못 정렬하거나, 인증서와 토큰의 만료 날짜를 잘못 계산하거나, 오버플로 값을 만나 완전히 충돌할 수 있습니다. 해결책은 간단합니다. 타임스탬프 저장에 64비트 부호 있는 정수로 이전하십시오. 64비트 타임스탬프는 에폭 전후 약 2920억 년의 날짜를 표현할 수 있어 실용적 관심을 훨씬 넘어섭니다. 대부분의 현대 운영체제, 프로그래밍 언어, 데이터베이스는 이미 내부적으로 64비트 타임스탬프를 씁니다. 위험은 레거시 코드, 임베디드 시스템, 여전히 프로덕션 중인 32비트 운영체제, 파일 시스템 메타데이터(예: FAT32의 타임스탬프 필드), BIGINT 대신 INT로 정의된 데이터베이스 컬럼에 있습니다. 개발자는 지금 시스템을 감사해야 합니다. 32비트에서 64비트 타임스탬프로의 이전은 2038년 이전에 이루어져야 하며, 실제로는 장기 레코드(주택 담보 대출, 인프라 자산, 법률 문서)를 보유한 시스템은 미래 날짜가 해당 필드에 입력되면서 훨씬 일찍 문제를 만날 수 있습니다.

초, 밀리초, 마이크로초 타임스탬프의 차이는 무엇인가요?

Unix 타임스탬프는 값의 자릿수로 구분되는 세 가지 흔한 정밀도가 있습니다. **초 (10자리)**: 원본이자 가장 흔한 Unix 타임스탬프 형식. `1741965432`는 특정 초를 나타냅니다. 사용처: Unix/Linux 시스템 호출(`time()`), 대부분의 Unix 유틸리티, JWT 토큰(`iat`, `exp` 클레임), HTTP 헤더(`Last-Modified`), 다수의 REST API. 현재 타임스탬프는 약 10자리입니다. **밀리초 (13자리)**: 1000분의 1초 정밀도. `1741965432000`은 위와 같은 순간을 1,000배 한 값입니다. 사용처: JavaScript의 `Date.now()`, Java의 `System.currentTimeMillis()`, Node.js, 대부분의 현대 JavaScript/TypeScript API, Redis, 다수의 데이터베이스 클라이언트. JSON API 응답에서 13자리 타임스탬프가 보이면 거의 확실히 밀리초입니다. **마이크로초 (16자리)**: 100만분의 1초 정밀도. `1741965432000000`은 같은 순간을 1,000,000배 한 값입니다. 사용처: PostgreSQL의 `TIMESTAMP`와 `TIMESTAMPTZ` 타입, Python의 `time.time_ns()`(나노초를 반환하긴 함), 고빈도 거래 시스템, 네트워크 패킷 분석 도구. 가장 흔한 실수는 정밀도를 섞는 것입니다. 예를 들어 초를 기대하는 함수에 밀리초 타임스탬프를 넘기는 경우입니다. 이는 약 11,574년 뒤의 날짜를 만듭니다. 작업 중인 API나 시스템의 문서를 항상 확인해 기대 정밀도를 파악하고 본 변환기의 자동 감지를 상식 검증에 사용하십시오.

Unix 시간은 윤초를 고려하나요?

아니요. Unix 시간은 윤초를 고려하지 않으며, 이는 정밀 시간 측정 응용에 알려진 한계 중 하나입니다. 윤초는 지구의 약간 불규칙한 자전과 UTC를 동기화하기 위해 국제 지구 자전 및 참조계 서비스(IERS)에서 때때로 삽입됩니다(이론상 제거도 가능하나 아직 한 번도 제거된 적은 없습니다). 2026년 현재 1972년 도입 이후 27회의 윤초가 삽입되었습니다. Unix 시간은 하루를 정확히 86,400초(24 × 60 × 60)로 가진 완전히 규칙적인 달력을 가정합니다. 윤초가 삽입되면 Unix 시간이 무시하는 초가 현실 세계에 생깁니다. 운영체제별로 처리 방식이 다릅니다. Linux는 전통적으로 삽입 지점 주변의 일정 기간 동안 시계를 약간 느리게 돌리는 방식(Google의 접근법 · "윤초 스미어링")으로 윤초를 "펴 바릅니다". 일부 시스템은 23:59:60 UTC에 해당 초를 중복시키고, 다른 시스템은 단순히 조정을 건너뛰고 시계가 드리프트하도록 둡니다. 웹 서비스, API, 데이터베이스, 비즈니스 로직 같은 대부분의 소프트웨어 응용에서 50년 이상 누적된 약 27초의 윤초 불일치는 완전히 무관합니다. 차이는 사람 대상 응용에 감지되지 않습니다. 윤초가 중요한 곳: GPS 동기화, 천문 관측, 패킷 네트워크 타이밍 프로토콜(PTP/IEEE 1588), Unix 타임스탬프와 TAI(국제 원자시)를 정밀하게 상관시켜야 하는 시스템. 이러한 범주에 해당한다면 윤초 인식을 명시적으로 지원하는 시간 측정 라이브러리를 쓰거나 TAI 타임스탬프로 직접 작업해야 합니다.

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

예. Unix 타임스탬프는 음수일 수 있으며 음의 타임스탬프는 Unix 에폭(1970년 1월 1일 00:00:00 UTC) 이전 날짜를 나타내는 정당하고 잘 정의된 방식입니다. 에폭 이전 각 초는 0에서 1씩 감소한 값에 대응합니다. 예를 들어 -1은 1969년 12월 31일 23:59:59 UTC를, -86400은 1969년 12월 31일 00:00:00 UTC(에폭 정확히 하루 전)를, -2208988800은 1900년 1월 1일 00:00:00 UTC를 나타냅니다. 대부분의 현대 프로그래밍 언어와 운영체제는 음의 타임스탬프를 지원합니다. Python의 `datetime.fromtimestamp(-86400)`은 1969년 12월 31일을 올바르게 반환합니다. JavaScript의 `new Date(-86400 * 1000)`도 같은 날짜를 올바르게 렌더링합니다. PostgreSQL은 타임스탬프를 8바이트 정수로 저장하고 에폭보다 수천 년 전의 날짜도 올바르게 처리합니다. 다만 중요한 주의사항이 있습니다. 일부 오래된 시스템, 라이브러리, 데이터베이스 드라이버는 음의 타임스탬프를 제대로 지원하지 않을 수 있습니다. 타임스탬프에 부호 없는 정수를 쓰는 32비트 시스템은 음수 값을 전혀 표현할 수 없습니다. UNSIGNED BIGINT나 DATETIME 타입으로 정의된 일부 데이터베이스는 음수 값을 거부하거나 먼 미래 날짜로 해석할 수 있습니다. 역사적 날짜(1970년 이전 모든 것)의 경우 이식성을 위해 음의 Unix 타임스탬프에 의존하기보다 ISO 8601 문자열이나 데이터베이스 기본 날짜 타입으로 저장하는 편이 더 안전합니다. 본 변환기는 음의 타임스탬프를 올바르게 처리하며 해당하는 1970년 이전 날짜를 표시합니다.

JavaScript, Python 등 각 언어에서 현재 Unix 타임스탬프는 어떻게 얻나요?

현재 Unix 타임스탬프를 얻는 방법은 모든 주요 프로그래밍 언어에서 간단합니다. **JavaScript / TypeScript:** ```javascript // Seconds (most APIs expect this) const seconds = Math.floor(Date.now() / 1000); // Milliseconds (JavaScript native) const milliseconds = Date.now(); ``` **Python:** ```python import time seconds = int(time.time()) # 1741965432 import datetime milliseconds = int(datetime.datetime.now(datetime.UTC).timestamp() * 1000) ``` **Go:** ```go import "time" seconds := time.Now().Unix() // int64 milliseconds := time.Now().UnixMilli() // int64 microseconds := time.Now().UnixMicro() // int64 ``` **Java:** ```java long seconds = System.currentTimeMillis() / 1000L; long milliseconds = System.currentTimeMillis(); // Or with java.time (Java 8+): long seconds2 = Instant.now().getEpochSecond(); ``` **PHP:** ```php $seconds = time(); // integer $milliseconds = round(microtime(true) * 1000); ``` **Ruby:** ```ruby seconds = Time.now.to_i milliseconds = (Time.now.to_f * 1000).to_i ``` **Bash / Shell:** ```bash date +%s # seconds date +%s%3N # milliseconds (GNU date) ``` 기억해야 할 가장 중요한 점은 JavaScript는 밀리초로 기본 동작하는 반면 사실상 다른 모든 언어는 기본적으로 초를 쓴다는 것입니다. 어떤 정밀도를 사용하는지 항상 명시하고 API 계약에 문서화해 통합 버그를 예방하십시오.

에폭 시간을 사람이 읽기 쉬운 날짜로 어떻게 변환하나요?

에폭 시간(Unix 타임스탬프)을 사람이 읽기 쉬운 날짜로 변환하는 빠른 방법이 세 가지 있습니다. **1. 이 온라인 변환기 사용(가장 빠름)** 위 입력란에 에폭 타임스탬프를 붙여넣으십시오. 본 도구는 초, 밀리초, 마이크로초 중 무엇인지 자동으로 감지하고 UTC, 로컬 시간대, ISO 8601, 상대 시간 형식으로 결과를 즉시 표시합니다. 복사 버튼으로 원하는 형식을 가져가십시오. **2. 코드 사용** JavaScript: `new Date(1741965432 * 1000).toISOString()`은 `'2025-03-14T15:37:12.000Z'`를 반환합니다. Python: `from datetime import datetime, UTC; datetime.fromtimestamp(1741965432, UTC)`도 같은 결과입니다. JavaScript는 밀리초를 기대하고 Python은 초를 기대한다는 점에 유의하십시오. 변환 버그의 가장 흔한 원인입니다. **3. 명령줄 사용** GNU date가 있는 Linux 또는 macOS: `date -d @1741965432`(Linux) 또는 `date -r 1741965432`(macOS). Windows PowerShell: `[DateTimeOffset]::FromUnixTimeSeconds(1741965432).DateTime`. 세 방법 모두 같은 결과를 만듭니다. 터미널을 열거나 코드를 쓰지 않고 빠른 답이 필요할 때는 위 온라인 변환기가 가장 빠른 선택입니다.

지금 Unix 타임스탬프는 얼마인가요?

현재 Unix 타임스탬프는 페이지 상단의 실시간 시계에 매초 갱신되어 표시됩니다. Unix 타임스탬프는 단순히 1970년 1월 1일 00:00:00 UTC 이후의 초 수이며 1초마다 정확히 1씩 증가합니다. 현재 타임스탬프를 프로그램으로 얻으려면: - **JavaScript**: `Math.floor(Date.now() / 1000)` (초) 또는 `Date.now()` (밀리초) - **Python**: `import time; int(time.time())` - **Bash**: `date +%s` 2026년 현재 Unix 타임스탬프는 17.7억 범위(10자리)입니다. 20억에 도달하는 시점은 2033년 5월 경이며, 32비트 시스템의 최대값(2,147,483,647)은 2038년 1월 19일 03:14:07 UTC에 도달합니다. 이른바 Y2038 문제입니다. 이 페이지를 북마크하면 현재 에폭 시간을 언제든 한 번의 클릭으로 확인할 수 있습니다.

API 응답의 타임스탬프를 디버그하고 싶은데 어떻게 변환하나요?

API 응답에서 타임스탬프 값을 복사하십시오(보통 "created_at"나 "timestamp" 같은 JSON 필드에 10자리 또는 13자리 숫자로 들어 있습니다). 위 입력란에 직접 붙여넣으면 본 도구가 초인지 밀리초인지 자동 감지해 UTC 날짜, 로컬 시간, ISO 8601 형식을 즉시 보여 줍니다. 타임스탬프가 JWT 토큰 안에 중첩되어 있다면 먼저 JWT 페이로드(Base64URL 인코딩)를 해석하여 iat, exp, nbf 필드를 추출한 뒤 그 값을 여기에 붙여넣으십시오. 일괄 디버깅에는 브라우저 콘솔에서 new Date(timestamp * 1000).toISOString() 스니펫을 사용해 개발 도구를 벗어나지 않고 여러 타임스탬프를 빠르게 확인하십시오.

Python/JavaScript/Go에서 현재 Unix 타임스탬프는 어떻게 얻나요?

JavaScript에서는 초는 Math.floor(Date.now() / 1000), 밀리초는 Date.now()를 사용하십시오. Python에서는 초에 import time; int(time.time())을, 밀리초에 int(time.time() * 1000)을 사용하십시오. Go에서는 초에 time.Now().Unix(), 밀리초에 time.Now().UnixMilli(), 마이크로초에 time.Now().UnixMicro()를 사용하십시오. JavaScript는 기본이 밀리초이고 Python과 Go는 기본이 초라는 점을 기억하십시오. 서로 다른 언어로 작성된 시스템을 통합할 때 타임스탬프 버그의 가장 흔한 단일 원인입니다. API가 기대하는 정밀도를 항상 OpenAPI/Swagger 사양에 문서화하십시오.

일광 절약 시간 전환 시 Unix 타임스탬프는 어떻게 되나요?

Unix 타임스탬프는 DST를 관측하지 않는 UTC를 기반으로 하므로 일광 절약 시간(DST) 변경의 영향을 전혀 받지 않습니다. 로컬 시간대에서 시계가 "앞당겨지거나" "되돌려질" 때 Unix 타임스탬프는 어떤 공백이나 반복 없이 매초 정확히 1씩 계속 증가합니다. 이는 로컬 날짜/시간 문자열보다 Unix 타임스탬프로 시간을 저장하는 주요 이점 중 하나입니다. 다만 DST 전환 중 Unix 타임스탬프를 로컬 시간으로 변환하면 같은 로컬 시간이 두 개의 서로 다른 Unix 타임스탬프에 대응할 수 있습니다(시계가 반복되는 "되돌림" 시간 동안). 타임스탬프는 항상 UTC로 저장하고 비교하며 표시 목적에서만 로컬 시간으로 변환하십시오.

밀리초 타임스탬프를 초로 변환하려면 어떻게 하나요?

밀리초 타임스탬프를 1000으로 나누고 소수 부분을 버리십시오. JavaScript: Math.floor(ms / 1000). Python: ms // 1000 (정수 나눗셈). 예: 1741965432000(밀리초)은 1741965432(초)가 됩니다. 밀리초 타임스탬프는 13자리 길이로, 초 타임스탬프는 10자리 길이로 식별할 수 있습니다. 본 도구는 정밀도를 자동 감지하므로 어느 형식이든 직접 붙여넣을 수 있습니다. 반대 변환(초에서 밀리초)은 단순히 1000을 곱합니다. 1741965432 * 1000 = 1741965432000. 초를 기대하는 함수에 밀리초 값을 실수로 넘기지 않도록 주의하십시오. 결과는 약 11,574년 뒤의 날짜가 됩니다.