01
데이터베이스와 API를 구분하세요
visits.visit_time은 이 형식이지만 확장 API의 lastVisitTime은 Unix 밀리초입니다. 짧은 정수도 유효할 수 있으므로 자릿수만으로 크롬 타임스탬프를 판별하지 않습니다. 필드 문서의 단위를 확인한 뒤 붙여 넣으세요.
날짜와 시간
WebKit 타임스탬프 변환마지막 마이크로초까지 확인
한 줄에 Chrome 정수 하나 또는 Z나 명시적인 시차가 있는 날짜를 입력하세요. 결과는 UTC로 표시됩니다.
WebKit 타임스탬프 변환
입력
결과
입력은 이 브라우저에서 처리되며 서버로 전송되지 않습니다.
옵션
Chrome 데이터베이스 기준: 1601-01-01 UTC · 1단위 = 1마이크로초.
행마다 부호 있는 십진 정수 또는 YYYY-MM-DDTHH:mm:ss[.소수 1–6자리]Z / ±HH:mm을 입력하세요. UTC로 변환한 연도는 0001–9999입니다.
0은 산술상 기준 날짜이지만 Chromium에서는 미설정일 수 있습니다. 64비트 부호 정수의 최솟값과 최댓값은 무한대 특수값으로 표시합니다.
UTC 소수는 여섯 자리입니다. Unix 초·밀리초는 내림하고 음수가 아닌 마이크로초 나머지를 함께 표시합니다.
최대 1,000개 물리적 행, 100,000 UTF-16 코드 단위. 양끝 공백은 제거하며 빈 행은 오류입니다.
모든 행에 날짜가 있어야 역방향으로 바꿀 수 있습니다. 오류와 무한대 특수값을 먼저 확인하세요.
입력하거나 예시를 불러오세요.
WebKit 타임스탬프 변환은 크롬 기록을 추출했을 때 보이는 긴 숫자를 날짜와 대조하는 데 유용합니다. 스프레드시트에서 마지막 자리가 반올림되었다면 복원할 수 없으므로 데이터베이스의 원래 정수를 준비하세요.
여기서 WebKit은 1601년부터 계산하는 Chrome/Chromium 데이터베이스 형식을 뜻합니다. 같은 브라우저라도 확장 API, JavaScript Date, 상대 시계는 다른 단위를 사용합니다. 숫자의 자릿수보다 출처를 먼저 확인해야 합니다.
WebKit 타임스탬프 변환으로 확인하는 차이
왕복해도 끝자리가 남습니다
WebKit 타임스탬프 변환에서 11644473600000001은 1970-01-01T00:00:00.000001Z가 됩니다. 다시 정수로 바꾸면 마지막 1이 보존됩니다. 밀리초까지만 보이는 날짜 도구에서 가려졌던 차이를 직접 대조할 수 있습니다.
잘못된 행도 원래 위치에 둡니다
한 행이 잘못되어도 나머지는 계속 처리합니다. 원문과 실제 줄 번호를 함께 남기므로 실패한 행이 사라져 결과가 한 줄씩 밀리는 일이 없습니다. 복사한 보고서에서도 원본 순서를 그대로 따라갈 수 있습니다.
출처와 시차부터 확인하세요
02
날짜에 시차를 붙이세요
역변환에는 Z 또는 ±HH:mm이 필요합니다. 기기의 시간대를 암묵적으로 쓰지 않습니다. 예제는 선택한 방향에 따라 바뀌며 미리보기에서 적용해야 입력을 교체합니다. 일곱 자리 이상의 소수는 잘라내지 않고 오류로 표시합니다.
03
최신 결과인지 확인하세요
자동 모드는 입력 후 350ms를 기다립니다. 끄면 버튼이나 Ctrl/Cmd+Enter로 실행할 수 있습니다. 입력을 수정하면 내보내기가 즉시 비활성화됩니다. 역방향 적용 후 한 번 실행 취소하면 이전 입력과 결과를 함께 복원합니다.
한 시각을 세 가지 Unix 단위로 비교
정수 문자열로 정밀도 유지
현재의 긴 카운터는 JavaScript 안전 정수 한도를 넘습니다. 계산은 정수로 수행하고 JSON에서는 정확한 카운터를 문자열로 저장합니다. 부동소수점 변환 때문에 홀수 끝자리가 사라지는 문제를 피하며, 이미 손실된 자리는 복구하지 않습니다.
몫과 나머지를 함께 제공
Unix 타임스탬프는 11644473600000000마이크로초를 뺀 뒤 구합니다. 정확한 Unix 마이크로초와 내림한 초·밀리초, 각 단위의 나머지를 함께 제공합니다. 초만 보고 마이크로초 차이까지 같다고 판단하지 마세요.
음수도 일관된 내림 적용
1601년 이전 날짜는 음의 WebKit 값입니다. 1970년의 1마이크로초 전은 Unix 초 -1과 나머지 999999로 표현합니다. 0 방향으로 잘라내는 정수 나눗셈과 구분하므로 경계 전후의 순서가 명확합니다.
전체 행을 담는 진단 보고서
최대 1000개 물리 행, UTF-16 단위 100000개를 처리합니다. 화면에서는 50행씩 늘려 볼 수 있고 복사·다운로드는 모든 행을 포함합니다. 원문, 해석, 행 번호, 오류를 함께 저장하여 일부 화면만 내보내는 혼동을 줄입니다.
형식과 기록의 의미는 별개입니다
- 자동 단위 감지 없음
- Unix, JavaScript, FILETIME, Safari 값을 자동 분류하지 않습니다. FILETIME은 같은 기준에서 100나노초 단위를 씁니다. 현대 WebKit API나 performance.now의 상대 시간까지 이 변환식으로 해석해서는 안 됩니다.
- 0과 무한대는 따로 확인
- 0은 산술 날짜와 possibleNull 안내를 함께 표시하며 실제 1601년 사건으로 단정하지 않습니다. 부호 있는 64비트 양 끝값은 Chromium 무한대 특수값으로 보존하고 날짜와 Unix 값을 생성하지 않습니다.
- UTC 0001–9999년만 표시
- 유한한 날짜는 시차를 반영한 UTC 기준으로 범위를 검사합니다. 이는 도구의 표시 한도이며 Chromium 정수 저장 범위보다 좁습니다. 범위를 벗어난 행은 오류가 되지만 주변의 정상 행은 변환됩니다.
- 모호한 날짜를 보정하지 않음
- 초와 명시적인 시차가 필요하며 시차는 ±14:00 이내입니다. -00:00, 없는 날짜, 윤초, 24:00, 소수 일곱 자리 이상은 거부합니다. 지역 이름이나 일광 절약 시간에 따른 추측도 수행하지 않습니다.
- 파일 대신 값만 입력
- History/Cookies 파일, 브라우저 기록 권한, 원격 URL, SQL 열 추출을 다루지 않습니다. 지수·16진수·따옴표로 감싼 JSON 숫자는 오류입니다. 앞뒤 공백은 정리하지만 빈 행은 삭제하지 않고 오류로 남깁니다.
- 입력 교체는 미리보기 후 적용
- 예제, 비우기, 역변환은 내용과 문자 수·행 수를 확인한 뒤 적용합니다. 한 번 실행 취소로 이전 입력과 방향, 결과를 복원합니다. 오류 또는 무한대가 있는 배치는 역변환할 수 없어 해당 행이 몰래 빠지지 않습니다.
WebKit 타임스탬프 변환 질문
시간대는 어떻게 처리하나요?
결과는 UTC로 통일하며 역변환 날짜에는 Z 또는 명시적인 시차가 필요합니다. 예를 들어 1970-01-01T09:00:00+09:00은 Unix 기준 시각과 같습니다. 기기의 시간대 설정에 따라 결과가 달라지지 않습니다.
음수 타임스탬프를 사용할 수 있나요?
네. 지원하는 날짜 범위에서 음의 WebKit 값은 1601년 이전을 뜻합니다. 음의 Unix 값은 1970년 이전이라는 다른 경계입니다. 숫자를 해석할 때 어느 기준을 사용했는지 반드시 함께 확인하세요.
왜 WebKit과 Unix의 기준이 다른가요?
Chromium의 base::Time이 Windows 기준인 1601-01-01 UTC를 사용하기 때문입니다. Unix는 1970년이 기준이므로 마이크로초로 11644473600000000의 차이를 먼저 보정해야 합니다. 단위만 바꾸어서는 날짜가 맞지 않습니다.
Chrome 쿠키의 타임스탬프를 날짜로 바꾸려면 어떻게 하나요?
원래 creation_utc 또는 expires_utc 필드가 이 마이크로초 형식인지 확인하고 정수를 붙여 넣으세요. UTC 결과를 해당 필드의 의미와 함께 해석해야 합니다. 확장 API에서 받은 값은 단위가 다를 수 있습니다.
열에 들어 있는 0은 무엇을 뜻하나요?
Chromium에서 초기화되지 않은 시간을 뜻할 수 있습니다. 산술 변환은 1601년을 가리키지만 실제 사건이 있었다는 의미는 아닙니다. 이 도구는 possibleNull을 표시하며 쿠키의 세션 여부 등은 원본 레코드로 확인해야 합니다.
예상과 다른 결과인가요?
내보내기 전에 끝자리 확인
WebKit 타임스탬프 변환으로 돌아가 확인 가능한 원본 값의 UTC 날짜와 나머지를 대조하세요. 특수값 안내를 읽고 전체 보고서를 저장할 수 있습니다.