타임스탬프 변환 도구
Unix 타임스탬프와 날짜/시간 형식 간 상호 변환
타임스탬프 → 날짜
날짜 → 타임스탬프
전 세계 시간대 비교
자주 사용하는 형식 예시
타임스탬프란?
타임스탬프(Timestamp)는 특정 시간을 나타내는 숫자 값입니다. Unix 타임스탬프는 1970년 1월 1일 00:00:00 UTC(Unix 에포크라고 함)부터 지정된 시간까지 경과한 초 수입니다. 컴퓨터 시스템에서 시간을 나타내는 표준 방식으로, 플랫폼과 시간대에 관계없이 일관된 특성을 가집니다. 타임스탬프는 초 단위(10자리 숫자)와 밀리초 단위(13자리 숫자)로 구분됩니다. 초 단위 타임스탬프는 주로 Unix/Linux 시스템에서 사용되고, 밀리초 단위는 JavaScript 등 프로그래밍 언어에서 주로 사용됩니다.
사용 방법
Timestamp to Date
- 왼쪽 카드에 Unix 타임스탬프를 입력하세요
- 대상 시간대를 선택하세요 (예: 베이징 시간 UTC+8)
- 변환 버튼을 클릭하여 변환된 날짜 및 시간을 확인하세요
- 결과 형식: 표준, ISO 8601, 중국어 형식 등
Date to Timestamp
- 오른쪽 카드에서 날짜와 시간을 선택하세요
- 해당 날짜 및 시간에 사용된 소스 시간대를 선택하세요
- 변환 버튼을 클릭하여 Unix 타임스탬프를 얻으세요
- 결과에는 초 및 밀리초 타임스탬프가 포함됩니다
시간대 팁
- 소스 값이 초를 사용하는지 밀리초를 사용하는지 확인하세요. 10자리와 13자리 타임스탬프를 혼용하는 것이 잘못된 날짜의 흔한 원인입니다.
- 사람이 읽을 수 있는 날짜를 변환할 때는 항상 의도된 시간대를 확인하세요. 특히 로그, 예약 작업, 지역 간 시스템에서 중요합니다.
활용 사례
기술 원리
유닉스 타임스탬프는 유닉스 에포크, 즉 1970-01-01T00:00:00Z부터 경과한 시간을 측정합니다. 이는 POSIX 시간이 모든 이후 시점을 레이블링하는 기준점입니다. POSIX 시간은 의도적으로 윤초를 무시합니다. 매 캘린더 일은 정확히 86,400초로 취급되므로, 윤초 삽입을 포함하는 두 타임스탬프는 엄밀한 원자시계 기준과 1초 차이가 나지만, 그 대신 에포크 초와 UTC 캘린더 필드 간 변환은 깔끔한 86,400 나눗셈으로 처리됩니다. 일상적으로 등장하는 두 형식은 초 단위(현재 10자리, 예: 1717000000)와 밀리초 단위(13자리, 예: 1717000000000)입니다. JavaScript의 Date.now()는 에포크 기준 밀리초를 반환하고 `new Date(ms)`는 밀리초를 기대하는 반면, Unix의 `date +%s`, Go의 time.Unix, 대부분의 데이터베이스 TIMESTAMP 컬럼은 초를 사용합니다. 길이 기반 감지가 일반적인 구분 방법입니다. 10자리 값을 초로 읽으면 2001~2286 범위에 해당하고, 같은 값을 밀리초로 읽으면 1970년대 내에 위치합니다. 타임스탬프를 표시하려면 시간대가 필요합니다. UTC는 접미사 `Z`로 표기하고, 다른 오프셋은 `±HH:MM`을 사용합니다(예: 한국 표준시 `+08:00`, 미국 동부 표준시 `-05:00`). ISO 8601은 여러 선택적 구분 기호를 허용하는 반면, RFC 3339는 구분 기호를 고정하고 명시적 오프셋을 요구하는 더 엄격한 프로파일이므로 API 사양에서는 일반적으로 RFC 3339를 요구합니다. 에포크 초를 32비트 부호 있는 정수에 저장하는 레거시 시스템은 최대 양수값 2147483647에서 오버플로우하며, 이는 2038-01-19T03:14:07Z로 디코딩됩니다(Y2038 문제). 64비트 저장소는 이 한계를 인간의 관심 범위를 훨씬 넘어서는 지점까지 밀어냅니다.
- 유닉스 에포크는 1970-01-01T00:00:00Z로 고정되어 있으며, POSIX 시간은 윤초를 무시하므로 매일은 정확히 86,400초로 취급됩니다.
- JavaScript Date.now()는 밀리초를 반환합니다. `Math.floor(Date.now() / 1000)`으로 초 단위 타임스탬프로 변환합니다.
- Y2038 한계: 부호 있는 32비트 타임스탬프는 2147483647 = 2038-01-19T03:14:07Z에서 오버플로우합니다. 64비트 저장소는 이를 방지합니다.
- ISO 8601 vs RFC 3339: RFC 3339는 명시적 오프셋(`Z` 또는 `±HH:MM`)을 요구하는 더 엄격한 ISO 8601 프로파일로, API와 로그에 권장됩니다.
- ECMAScript Date는 에포크 기준 ±100,000,000일(약 ±273,785년)로 제한되며, 이것이 `new Date(8.64e15)`와 `new Date(-8.64e15)`가 절대 상한인 이유입니다.
- JWT의 `exp`, `iat`, `nbf` 클레임, `Cache-Control: max-age`, Cookie `Expires`는 모두 유닉스 초를 사용합니다(RFC 7519, RFC 7234). 따라서 `Math.floor(Date.now()/1000)`에 직접 더하거나 빼면 됩니다.
- 시간대는 렌더링된 날짜/시간에 영향을 주지만 타임스탬프 값 자체에는 영향을 주지 않습니다. 같은 에포크 초도 UTC+8과 UTC-5에서 다른 시각으로 표시됩니다.
예시
10자리 Unix 타임스탬프를 사람이 읽는 날짜로 변환
입력: 1781526600
UTC: 2026-06-15 12:30:00
베이징 (UTC+8): 2026-06-15 20:30:00
ISO 8601: 2026-06-15T12:30:00Z
POSIX: IEEE 1003.1은 Unix 시간을 1970-01-01 00:00:00 UTC(에포크) 이후의 초 수로 정의
ISO: ISO 8601은 명확한 날짜·시간 표기를 위한 YYYY-MM-DDThh:mm:ssZ 형식을 정의날짜를 다시 타임스탬프로 변환
입력: 2026-01-01 00:00:00 (UTC)
초 (10자리): 1767225600
밀리초 (13자리): 1767225600000
Unix 명령: date -d @1767225600
참고: JavaScript의 Date.getTime()은 밀리초를, Python의 time.time()은 초(부동소수점)를 반환
POSIX: time_t 타입은 전통적으로 32비트 또는 64비트 부호 있는 정수초와 밀리초 구분하기
1781526600 -> 10자리, 초 -> 2026-06-15 12:30:00 UTC
1781526600000 -> 13자리, 밀리초 -> 2026-06-15 12:30:00.000 UTC
흔한 버그: 13자리 값을 초로 읽으면 약 74000년이 됨
구분 방법: 10~11자리 = 초 (1970~2286), 13자리 = 밀리초 (JavaScript 기본값)JWT의 exp 클레임 디코딩
JWT 페이로드: { "exp": 1798617600 }
디코딩 결과: 2027-01-01 00:00:00 UTC
현재 시각: 1781526600
남은 유효: 17,091,000초 (약 198일 남음)
RFC: RFC 7519 섹션 2는 NumericDate를 에포크 이후의 초 수로 정의Y2038 경계 검사
32비트 부호 있는 최대 타임스탬프: 2147483647
디코딩 결과: 2038-01-19 03:14:07 UTC
1초 후: 2147483648 -> 구형 32비트 시스템에서 오버플로 발생
해결: 64비트 time_t 사용 (최신 Linux/macOS 기본) 또는 ISO 8601 문자열로 저장
POSIX: 32비트 time_t 시스템은 2038-01-19 이후 값이 한 바퀴 돌게 됨자주 묻는 질문
Unix 타임스탬프란 무엇인가요?
1970-01-01 00:00:00 UTC, 즉 'Unix epoch' 이후 경과된 초 수입니다. JavaScript와 많은 API는 동일한 epoch부터의 밀리초 단위(Unix 타임스탬프 × 1000)를 사용합니다. 이 페이지는 두 형식 모두 받아들이며 로컬 시간과 UTC로 해당 날짜를 표시합니다.
초, 밀리초, 마이크로초, 나노초의 차이는?
시스템마다 사용하는 정밀도가 다릅니다. Unix `time()`은 초를 반환합니다. JavaScript Date.now()는 밀리초를 반환합니다. Java Instant는 나노초를 지원합니다. 이 페이지는 자릿수로 자동 감지합니다: 10자리 = 초(2001~2286년), 13자리 = 밀리초, 16자리 = 마이크로초, 19자리 = 나노초.
왜 2038년 1월 19일이 중요한가요?
이른바 '2038년 문제'입니다. 32비트 부호 있는 Unix 타임스탬프는 2038-01-19 03:14:07 UTC에 오버플로됩니다. 32비트 time_t를 여전히 사용하는 시스템은 1901년으로 되돌아갑니다. 최신 64비트 시스템은 수십억 년간 영향을 받지 않지만, 레거시 임베디드 시스템은 수정이 필요합니다.
시간대는 어떻게 처리되나요?
Unix 타임스탬프는 본질적으로 UTC입니다. 페이지는 로컬 시간, UTC를 표시하며, 추가 표시를 위해 임의의 IANA 시간대(Asia/Shanghai, America/New_York, Europe/London)를 선택할 수 있습니다. 일광 절약 시간은 시간대별로 자동 적용됩니다.
왜 'YYYY-MM-DD' 파싱이 어떤 곳에서는 UTC로 가정되나요?
시간대 없는 ISO 8601 날짜는 모호합니다. JavaScript의 Date 생성자는 날짜만 있는 문자열은 UTC로, 날짜+시간 문자열은 로컬로 처리합니다 — 하루 차이 버그의 악명 높은 원인입니다. 이 페이지는 어떤 시간대가 적용되는지 명시적으로 보여줍니다.
변환은 로컬에서 이루어지나요?
네. 계산은 JavaScript Date와 Intl.DateTimeFormat으로 처리됩니다. 어떤 타임스탬프도 업로드되지 않습니다.
미래 타임스탬프를 생성할 수 있나요?
네. 미래 날짜를 선택하면 페이지가 해당 타임스탬프를 반환합니다. JWT exp 클레임 설정, cron 작업 테스트 날짜, 코드의 캐시 만료 시간 설정 등에 유용합니다.