타임스탬프 디코더

Unix 타임스탬프란?

Unix 타임스탬프(Epoch 시간 또는 POSIX 시간이라고도 함)는 Unix 에포크인 1970년 1월 1일 00:00:00 UTC부터 경과한 초의 누적값으로 시간을 추적하는 시스템입니다. 이 간단한 숫자 표현은 전 세계 컴퓨팅 시스템에서 시간 데이터를 저장하고 전송하는 보편적 표준이 되었습니다.

Unix 타임스탬프는 세 가지 정밀도로 사용됩니다: 초 (10자리, 예: 1350508407), 밀리초 (13자리, 예: 1350508407000), 마이크로초 (16자리). 대부분의 프로그래밍 언어와 데이터베이스는 초 또는 밀리초를 기본 정밀도로 사용합니다. 타임스탬프는 타임존에 독립적이며 항상 UTC를 나타내므로, 서버가 여러 타임존에 분산된 시스템에 이상적입니다.

지원 포맷

이 도구는 다양한 기술에서 사용되는 16개 시간 기반 포맷의 자동 감지와 변환을 지원합니다:

사용 방법

입력 필드에 타임스탬프 또는 시간 기반 ID를 붙여넣기만 하면 됩니다. 도구가 자동으로 포맷을 감지하고, 디코딩된 시간과 함께 16개 지원 포맷으로의 변환 결과를 표시합니다. 현재 시간 버튼을 클릭하면 모든 포맷으로 현재 시간을 볼 수 있고, 날짜/시간 선택기를 사용하면 특정 날짜를 변환할 수 있습니다. 각 변환 값에는 복사 버튼이 있어 빠르게 클립보드에 복사할 수 있습니다. 입력이 모호한 경우(예: Snowflake ID 또는 .NET Ticks일 수 있는 큰 숫자), 드롭다운에서 올바른 포맷을 선택할 수 있습니다.

MongoDB ObjectId 구조

MongoDB ObjectId는 MongoDB의 모든 문서에 자동 생성되는 12바이트(24자리 16진수) 식별자입니다. 그 구조에는 유용한 메타데이터가 인코딩되어 있습니다:

• 바이트 0-3: Unix 타임스탬프(초) (4바이트) — 이것이 우리가 디코딩하는 부분입니다
• 바이트 4-8: 머신과 프로세스에 고유한 랜덤 값 (5바이트)
• 바이트 9-11: 랜덤 값으로 초기화된 증가 카운터 (3바이트)

예를 들어, ObjectId 507f1f77bcf86cd799439011은 507f1f77로 시작하며, 이는 Unix 타임스탬프 1350508407 — 2012년 10월 17일 21:13:27 UTC로 변환됩니다. 이러한 구조 덕분에 ObjectId는 생성 시간순으로 자연 정렬되며, 별도의 createdAt 필드 없이도 MongoDB 문서의 정확한 생성 시간을 추출할 수 있습니다.

Snowflake ID 구조

Snowflake ID는 대규모 분산 ID 생성을 위해 설계된 64비트 정수입니다. 2010년 Twitter에서 처음 만들어졌으며, Discord 등 다른 플랫폼에서도 서로 다른 에포크 시작일로 채택했습니다.

비트 구조는 동일합니다: 미사용 부호 비트 1개 + 밀리초 타임스탬프 41비트 + 워커/데이터센터 ID 10비트 + 시퀀스 번호 12비트. 핵심 차이는 에포크입니다:

• Twitter: 에포크 = 2010년 11월 4일 (1288834974657ms) — Snowflake 출시일
• Discord: 에포크 = 2015년 1월 1일 (1420070400000ms) — Discord 자체 에포크

타임스탬프를 추출하려면: ID를 22비트 오른쪽 시프트하여 워커와 시퀀스 비트를 제거한 후, 플랫폼별 에포크 오프셋을 더합니다. 동일한 Snowflake ID 숫자라도 어떤 에포크를 사용하느냐에 따라 완전히 다른 날짜로 디코딩되므로, 올바른 플랫폼을 선택하는 것이 필수적입니다.

UUID v1 & v7 구조

UUID(범용 고유 식별자) 버전 1과 7은 모두 타임스탬프를 포함하지만 방식이 다릅니다. UUID v1은 RFC 4122에서 정의되고 RFC 9562에서 업데이트되었으며, 1582년 10월 15일(그레고리력 개혁)부터 100나노초 단위로 측정한 60비트 타임스탬프를 사용합니다. 타임스탬프는 time_low(32비트), time_mid(16비트), time_hi(12비트) 세 필드에 분산되어 있어 변환 전 재조합이 필요합니다.

UUID v7은 RFC 9562(2024)에서 도입되었으며 더 간단한 방식을 취합니다: 처음 48비트에 표준 Unix 밀리초 타임스탬프가 포함됩니다. 따라서 UUID v7은 생성 시간순으로 자연 정렬되며 디코딩이 훨씬 쉽습니다.

ULID 구조

ULID(범용 고유 사전순 정렬 가능 식별자)는 Crockford Base32로 인코딩된 26자 문자열입니다. 처음 10자에 48비트 Unix 밀리초 타임스탬프가 인코딩되고, 나머지 16자에 80비트의 암호학적 랜덤 데이터가 포함됩니다. UUID와 달리 ULID는 사전순 정렬이 시간순 정렬과 동일하도록 설계되었습니다. Crockford Base32 알파벳은 숫자 1, 0과의 혼동을 방지하기 위해 I, L, O, U를 제외합니다.

KSUID, CUID & XID

KSUID(K-정렬 가능 고유 식별자)는 Segment에서 만든 27자 base62 문자열로, 20바이트를 나타냅니다: 커스텀 에포크(2014년 5월 13일) 기준 4바이트 Unix 타임스탬프 + 16바이트 랜덤 페이로드. 자연 정렬 가능하며 고처리량 분산 시스템용으로 설계되었습니다.

CUID v1은 "c" 문자로 시작하고 24자가 뒤따릅니다. "c" 다음 8자에 base36으로 인코딩된 생성 타임스탬프(Unix 에포크 기준 밀리초)가 포함되며, 이어서 카운터, 머신 핑거프린트, 랜덤 데이터가 옵니다. 참고: CUID v1은 타임스탬프 노출 우려로 CUID v2에 의해 대체되었습니다.

XID는 Go 생태계의 20자 base32hex 인코딩 식별자입니다. 12바이트 바이너리 구조에 4바이트 Unix 타임스탬프(초), 3바이트 머신 ID, 2바이트 프로세스 ID, 3바이트 카운터가 포함됩니다.

Windows FILETIME, Excel & .NET Ticks

Windows FILETIME은 1601년 1월 1일 UTC부터 100나노초 단위로 계산합니다. Active Directory 타임스탬프, Windows 파일 메타데이터, Chrome 브라우저 타임스탬프에서 사용됩니다. Unix 시간으로 변환하려면 에포크 오프셋(116,444,736,000,000,000)을 빼고 10,000으로 나눕니다.

Excel Serial Date는 1900년 1월 1일(시리얼 1)부터 일수를 세며, 소수 부분은 시간을 나타냅니다. Lotus 1-2-3 호환 버그로 Excel은 1900년을 윤년으로 잘못 처리하여 시리얼 60 = 1900년 2월 29일(존재하지 않는 날짜)입니다. 시리얼 25569 = 1970년 1월 1일(Unix 에포크).

.NET DateTime.Ticks는 0001년 1월 1일 UTC부터 100나노초 단위로 계산합니다. Unix 에포크까지의 오프셋은 621,355,968,000,000,000 틱입니다.

macOS CFAbsoluteTime & Sonyflake

macOS CFAbsoluteTime(Core Foundation Absolute Time)은 2001년 1월 1일 00:00:00 UTC(Apple의 기준 날짜)부터 초 단위로 측정합니다. macOS/iOS 시스템 로그, Core Data 타임스탬프, Safari 브라우저 데이터에서 사용됩니다. Unix 에포크로부터의 오프셋은 978,307,200초입니다.

Sonyflake는 Sony에서 만든 63비트 ID로, 39비트 시간(2014년 9월 1일부터 10밀리초 단위), 8비트 시퀀스, 16비트 머신 ID로 구성됩니다. 타임스탬프를 추출하려면 24비트 오른쪽 시프트 후 10을 곱하여 밀리초로 변환하고, 에포크 오프셋(1,409,529,600,000ms)을 더합니다.

개인정보 보호 및 보안

이 도구는 클라이언트 사이드 JavaScript를 사용하여 모든 처리를 브라우저에서 수행합니다. 어떤 데이터도 서버로 전송되지 않습니다. 타임스탬프, ID, 디코딩 결과는 사용자의 기기를 벗어나지 않습니다. 소스 코드는 페이지에 완전히 공개되어 있으며, 브라우저의 개발자 도구로 직접 확인할 수 있습니다.