WebKit 타임스탬프와 Unix 타임스탬프

Study/Forensics

WebKit 타임스탬프와 Unix 타임스탬프

imaginefuture-1 2025. 2. 23. 12:58

1. WebKit 타임스탬프와 Unix 타임스탬프란?

📌 WebKit Timestamp

WebKit(Chrome, Safari 등)에서 사용하는 타임스탬프 형식.
기준 시간: 1601년 1월 1일 00:00:00 UTC
단위: 마이크로초(1,000,000분의 1초, 10⁻⁶초)
사용 예시:
- Chrome의 History DB (start_time, last_visit_time 등)
- WebKit 기반 브라우저의 쿠키, 캐시, 방문 기록 저장

📌 Unix Timestamp (Epoch Time)

Unix 시스템에서 널리 사용하는 시간 형식.
기준 시간: 1970년 1월 1일 00:00:00 UTC
단위: 초 (seconds)
사용 예시:
- 대부분의 운영체제 (Linux, MacOS, Windows 일부)
- 프로그래밍 언어 (Python, JavaScript 등)
- 네트워크 프로토콜, 파일 시스템, 데이터베이스

2. WebKit 타임스탬프와 Unix 타임스탬프의 차이

WebKit Timestamp Unix Timestamp

기준 (Epoch Time)	1601년 1월 1일	1970년 1월 1일
단위	마이크로초 (1,000,000분의 1초)	초 (1초 단위)
사용처	Chrome, Safari, WebKit 기반 앱	Unix/Linux 시스템, 대부분의 프로그래밍 환경
형식 예시	13223576418000000 (마이크로초)	1712416601 (초)

변환 공식
WebKit → Unix 변환:

Unix Timestamp = (WebKit Timestamp / 1,000,000) - 11644473600

11644473600 = 1970년 1월 1일 00:00:00 UTC까지의 초 단위 차이
1,000,000으로 나누는 이유: WebKit은 마이크로초 단위지만 Unix는 초 단위라서 변환 필요

Unix → WebKit 변환:

WebKit Timestamp = (Unix Timestamp + 11644473600) * 1,000,000

3. 왜 WebKit과 Unix가 서로 다른 기준을 사용하나? (역사적 이유)

🔹 Unix Timestamp의 역사

1970년 1월 1일을 기준으로 삼은 이유:
- Unix 시스템이 1969~1970년에 개발됨.
- 당시 컴퓨터 메모리가 제한적이었기 때문에 최소한의 데이터 크기로 시간을 저장하는 방식이 필요함.
- 초 단위의 정수값만 저장하는 것이 효율적이었고, 32비트 정수형으로 표현 가능했음.
- 32비트 정수형으로는 2038년 1월 19일까지 표현 가능 (Year 2038 Problem 존재).

🔹 WebKit Timestamp의 역사

1601년 1월 1일을 기준으로 삼은 이유:
- Windows NT 파일 시스템 (NTFS) 및 Microsoft FILETIME과의 호환성을 위해.
- NTFS 파일 시스템과 Windows API는 1601년 1월 1일 기준 마이크로초 단위 타임스탬프를 사용함.
- WebKit(Apple, Google, Microsoft)이 이 방식을 차용하여 Chrome/Safari의 방문 기록, 쿠키 저장 방식을 Windows 시스템과 쉽게 연동할 수 있도록 만듦.
- 마이크로초(µs) 단위로 저장하면 보다 정밀한 시간 기록이 가능하다는 장점이 있음.

4. 왜 WebKit Timestamp를 Unix Timestamp로 변환해야 할까?

대부분의 시스템(서버, 로그 분석, 데이터베이스)은 Unix Timestamp를 사용함.
파일 다운로드 시작 시간 같은 특정 정보를 찾을 때, WebKit 타임스탬프를 Unix 형식으로 변환해야 제대로 분석할 수 있음.
예를 들어, 1712416601 같은 Unix Timestamp는 GMT 2024년 4월 6일 15:16:41을 의미하지만, WebKit의 start_time 값은 마이크로초 단위이므로 변환 없이는 사용할 수 없음.

📌 정리

WebKit Timestamp Unix Timestamp

기준(Epoch Time)	1601년 1월 1일 UTC	1970년 1월 1일 UTC
단위	마이크로초 (10⁻⁶ 초)	초 (10⁰ 초)
사용 환경	Chrome, Safari, WebKit 기반 DB (History, 쿠키, 다운로드 기록)	Unix/Linux 시스템, 서버, 프로그래밍 언어
왜 다를까?	Windows NTFS 호환성 및 높은 정밀도	단순하고 효율적인 저장 방식 (초 단위)

🚀 즉, WebKit은 Microsoft/Windows NTFS 호환성을 유지하기 위해, Unix는 단순하고 가벼운 초 단위 포맷을 사용하기 위해 서로 다른 기준을 채택한 것!

WebKit Timestamp의 기준이 1601년인 이유 (역사적 배경)

🔹 1601년 1월 1일을 기준으로 삼은 이유:

WebKit의 타임스탬프가 1601년 1월 1일을 기준으로 하는 이유는 Microsoft Windows와 NTFS 파일 시스템의 역사와 깊은 관련이 있음.

Windows NT & NTFS에서 FILETIME의 시작점이 1601년
- Microsoft Windows는 **NTFS (New Technology File System)**라는 파일 시스템을 사용함.
- NTFS는 파일의 생성 시간, 수정 시간, 접근 시간 등을 기록하기 위해 "Windows FILETIME" 형식을 사용함.
- FILETIME은 1601년 1월 1일 00:00:00 UTC부터 시작하여 100나노초(10⁻⁷초) 단위로 시간을 저장함.
FILETIME의 1601년 기준은 Windows NT의 선택
- 1993년, Microsoft는 새로운 운영체제인 Windows NT를 개발하면서 파일 시스템의 시간 관리를 위한 새로운 포맷을 정의함.
- 당시 Microsoft는 과거의 레거시 DOS 및 FAT 파일 시스템과 호환성을 유지하면서도, 더 정밀한 타임스탬프가 필요했음.
- Unix가 1970년을 기준으로 삼았던 것처럼, Microsoft는 1601년 1월 1일을 기준으로 삼기로 결정함.
1601년이 선택된 이유:
- 1582년, **그레고리력(Gregorian Calendar)**이 도입되면서, 기존의 율리우스력(Julian Calendar)을 대체하게 됨.
- Microsoft는 날짜 계산 시 그레고리력을 사용하는 최초의 완전한 세기가 1601년부터 시작된다고 판단했음.
- 즉, 1601년 이전은 율리우스력과의 충돌이 있어 계산이 복잡해질 수 있었기 때문에 1601년을 기준으로 설정한 것.
WebKit이 1601년을 따른 이유
- WebKit 기반의 Chrome, Safari 등은 쿠키, 방문 기록, 다운로드 시간을 저장할 때 Windows의 NTFS 및 FILETIME 형식을 그대로 차용함.
- NTFS의 FILETIME과 호환되도록 하기 위해 WebKit은 동일한 1601년 1월 1일을 기준으로 함.
- WebKit Timestamp는 마이크로초(µs) 단위로 저장되지만, 기본적인 기준점(Epoch Time)은 Windows NTFS와 동일하게 설정된 것.

📌 정리

시스템 기준 (Epoch Time) 단위

Unix Timestamp	1970년 1월 1일	초 (1초 단위)
Windows NT FILETIME	1601년 1월 1일	100나노초 (10⁻⁷초) 단위
WebKit Timestamp	1601년 1월 1일	마이크로초 (10⁻⁶초) 단위

🔹 결론: 왜 1601년?

Microsoft Windows NT & NTFS의 파일 시간 관리 시스템(FILETIME)과 호환하기 위해.
1601년이 그레고리력이 완전하게 적용된 최초의 세기이기 때문.
WebKit은 Windows와의 호환성을 위해 1601년 기준을 유지함.

✅ 즉, WebKit이 1601년을 기준으로 한 이유는 단순히 NTFS와 Windows의 FILETIME을 그대로 따라갔기 때문!