01
似た名前のAPIに注意する
データベースのvisits.visit_timeと、拡張機能APIのlastVisitTimeは同じ単位ではありません。後者はUnixミリ秒です。短い整数も形式上は有効なので、Chromeタイムスタンプという名前や桁数だけでは判断できません。
日時
WebKitタイムスタンプ変換最後の1マイクロ秒まで確認
Chromeの整数値、またはZか時差を付けた日時を1行に1件入力します。結果はUTCで表示します。
WebKitタイムスタンプ変換
入力
結果
入力はこのブラウザー内で処理され、サーバーには送信されません。
オプション
Chromeデータベースの起点：1601-01-01 UTC。1単位は1マイクロ秒です。
1行に符号付き十進整数、またはYYYY-MM-DDTHH:mm:ss[.小数1〜6桁]Z／±HH:mmを入力。UTC換算後の年は0001〜9999です。
ゼロは計算上の起点日時を持ちますが、Chromiumでは未設定の可能性があります。符号付き64ビット整数の両端は無限大の特殊値として扱います。
UTCは小数6桁で表示。Unixの秒とミリ秒は負の無限大へ切り下げ、非負のマイクロ秒余りを残します。
最大1,000物理行、100,000 UTF-16コード単位。両端の空白を除去し、空行はエラーにします。
全行に日時がある場合のみ逆変換できます。エラー行や無限大の特殊値を先に確認してください。
入力するかサンプルを読み込んでください。
WebKitタイムスタンプ変換は、Chromeの閲覧履歴から取り出した長い整数を確かめるためのツールです。表計算ソフトを経由して末尾が丸められていると元には戻せないため、まずデータベースの原文を用意してください。
ここで扱うWebKit形式は、1601年を起点にしたChrome／Chromiumのマイクロ秒です。同じブラウザーでもAPIによって起点と単位が異なります。桁数だけを見て形式を決めず、値を取り出した場所を確認しましょう。
WebKitタイムスタンプ変換で確かめられること
往復しても末尾を落とさない
WebKitタイムスタンプ変換では11644473600000001が1970-01-01T00:00:00.000001Zになります。結果を逆方向に戻しても最後の1が残ります。ミリ秒表示では見えない差を、6桁の小数で確認できます。
失敗した行も対応を保つ
途中に不正な文字列があっても、前後の行は処理します。元の文字列と物理行番号を一緒に残すため、エラーだけ消えて結果の並びがずれることはありません。抽出元と照合しやすい報告になります。
列の種類と時差を先に確認
02
日時の末尾に時差を書く
逆変換にはZまたは±HH:mmが必要です。パソコンのタイムゾーンを暗黙に使いません。サンプルは選んだ方向に合わせて切り替わり、内容を確認してから適用できます。小数7桁以上は切り捨てずにエラーになります。
03
更新後の結果を使う
自動変換は編集から350ミリ秒待って実行します。オフにするとボタンかCtrl/Cmd+Enterで実行できます。編集直後は書き出しを無効にし、逆変換の適用後は入力と結果を一度に元へ戻せます。
一つの時刻を三つのUnix単位で照合
大きな整数を文字列で保持
現在の値はJavaScriptの安全な整数範囲を超えています。計算に整数演算を使い、JSONの精密なカウンターは文字列で保存します。浮動小数点へ変換してから引き算すると失われる末尾の桁を守ります。
秒とミリ秒の余りも出力
Unixマイクロ秒は入力から11644473600000000を引いた値です。秒・ミリ秒の整数商と、それぞれのマイクロ秒余りも並べます。整数の秒だけで微小な差を表したつもりにならず、余りまで確認できます。
起点より前の日時も扱う
対応範囲内で1601年より前ならWebKit値は負数になります。1970年の1マイクロ秒前はUnix秒が-1、余りが999999です。ゼロ方向への切り捨てと区別した計算規則を採用しています。
行単位の結果をまとめて残す
上限は物理1000行、100000 UTF-16単位です。最初に50行表示し、50行ずつ追加できます。コピーとダウンロードには表示済みの部分だけでなく、全行の入力、解釈、エラーを含めます。
変換できる範囲と判断できない意味
- 形式の自動判別はしない
- Unix、JavaScript、FILETIME、Safariの値を自動で振り分けません。FILETIMEは同じ起点でも100ナノ秒単位です。現行WebKitのAPIやperformance.nowも別途確認が必要で、すべてをこの形式として扱うことはできません。
- ゼロは出来事の証拠ではない
- 0にはpossibleNullの注意を付けます。1601年という表示は算術結果であり、実際の記録日時とは限りません。符号付き64ビットの最小・最大値は無限大の特殊値として残し、日時やUnix値を生成しません。
- UTCで0001〜9999年に限定
- 有限の日時はUTCへ正規化したあとで範囲を検査します。これは本ツールの表示上の制限であり、Chromiumの保存範囲ではありません。範囲外の行があっても、ほかの有効な行の処理は続けます。
- あいまいな日時を補正しない
- 秒と明示的な時差が必要で、許容する時差は±14:00以内です。-00:00、存在しない日付、うるう秒、24:00、小数7桁以上は拒否します。地域名によるタイムゾーンや夏時間の推測も行いません。
- 値の列だけを入力する
- HistoryやCookiesのファイルを読み込まず、履歴アクセス権限も求めません。URL取得やSQL列選択は対象外です。指数表記、16進数、引用符付きJSON数値は拒否し、前後の空白は除去しても空行はエラーとして残します。
- 入力の置換は確認して適用
- サンプル、クリア、逆変換は、置換内容と文字数・行数をプレビューしてから適用します。一度だけ入力、方向、結果を同時に戻せます。エラーや無限大を含む一覧の逆変換は無効にし、行の脱落を防ぎます。
WebKitタイムスタンプ変換のよくある質問
Chromeはこの数値をどこに保存していますか？
代表例はHistory内のvisits.visit_time、urls.last_visit_timeや、Cookies内のcreation_utc、expires_utcです。抽出したデータベースの仕様を確認してください。このページ自体がファイルを開いたり閲覧履歴を読み出したりすることはありません。
なぜ1601年なのですか？
Chromiumのbase::TimeはWindowsと同じ1601-01-01 UTCを起点にしています。Unixの起点との差は11644473600000000マイクロ秒です。単に百万で割るだけでは、この起点の違いが残ってしまいます。
これらの列の0は何を意味しますか？
Chromiumでは未初期化の時刻をゼロで表すことがあります。計算上は1601年になりますが、その日時にイベントが起きたとは断定できません。possibleNullの表示を見て元の列やレコードの状態を調べてください。
ChromeのCookieのタイムスタンプを日時に変換するには？
元のマイクロ秒カウンターであることを確認し、WebKit → 日時に貼り付けます。UTC結果をCookieの列名と合わせて読みます。ゼロ値の意味やセッションCookieかどうかは、その整数だけで判断できません。
Windows FILETIMEと同じ形式ですか？
起点は同じでも、こちらはマイクロ秒、FILETIMEは100ナノ秒です。同じ通常の時刻ならFILETIMEのカウンターは10倍になります。出所の単位に合うツールを選び、名前が似ているだけで入力を流用しないでください。
予想と違う結果ですか？