Datum und Zeit
Pro Zeile einen Chrome-Datenbankwert oder ein ISO-Datum mit Z beziehungsweise explizitem UTC-Offset eingeben.
Die Eingabe wird in diesem Browser verarbeitet und nicht an einen Server gesendet.
Chrome-Datenbankepoche: 1601-01-01 UTC · eine Einheit = eine Mikrosekunde.
Je Zeile eine vorzeichenbehaftete Dezimalzahl oder YYYY-MM-DDTHH:mm:ss[.1–6 Stellen]Z / ±HH:mm. UTC-Jahre: 0001–9999.
Null hat ein rechnerisches Datum, kann in Chromium aber „nicht gesetzt“ bedeuten. Die beiden int64-Grenzwerte stehen für Unendlich und erhalten kein Datum.
UTC zeigt sechs Nachkommastellen. Unix-Sekunden und Millisekunden werden abgerundet; Mikrosekundenreste bleiben nichtnegativ.
Bis zu 1.000 physische Zeilen und 100.000 UTF-16-Codeeinheiten. Äußerer Leerraum wird entfernt; Leerzeilen sind Fehler.
Die Gegenrichtung ist nur verfügbar, wenn jede Zeile ein Datum enthält. Fehler und Unendlich-Werte zuerst prüfen.
Eingabe hinzufügen oder ein Beispiel laden.
Wer WebKit-Zeitstempel umrechnen möchte, findet in einem Chrome-Verlaufsexport oft lange Ganzzahlen. Kopieren Sie die ursprünglichen Werte: Hat eine Tabellenkalkulation die letzten Stellen bereits gerundet, kann die Umrechnung sie nicht wiederherstellen.
WebKit bezeichnet hier das verbreitete Chrome/Chromium-Datenbankformat ab 1601. Browser-APIs mit ähnlich benannten Feldern können andere Einheiten verwenden. Entscheidend ist die Quelle des Werts, nicht seine Länge.
Hier können Sie WebKit-Zeitstempel umrechnen und die letzte Stelle im Rückweg prüfen: 11644473600000001 ergibt 1970-01-01T00:00:00.000001Z. Alle sechs Nachkommastellen bleiben sichtbar, auch wenn ein anderer Datumsbetrachter nur Millisekunden zeigt.
Ein ungültiger Eintrag hält die benachbarten Zeilen nicht auf. Originaltext und physische Zeilennummer bleiben im Bericht erhalten. Dadurch rutschen Ergebnisse nicht zusammen, wenn mitten in einer exportierten Spalte ein Wert fehlt oder falsch formatiert ist.
visits.visit_time in der Datenbank und lastVisitTime in der Erweiterungs-API sind verschieden: Die API verwendet Unix-Millisekunden. Auch ein kurzer Chrome-Zeitstempel kann gültig sein. Das Werkzeug erkennt die Einheit deshalb nicht anhand der Ziffernzahl.
Die Gegenrichtung verlangt Z oder ±HH:mm, unabhängig von der Zeitzone Ihres Rechners. Beispiel folgt der gewählten Richtung und zeigt vor dem Ersetzen eine Vorschau. Mehr als sechs Nachkommastellen führen zu einem Fehler statt zu einer stillen Kürzung.
Automatik wartet 350 ms nach einer Änderung. Ohne Automatik stehen die Schaltfläche und Ctrl/Cmd+Enter bereit. Änderungen sperren den Export sofort. Die Gegenrichtung benötigt für jede Zeile ein Datum; Rückgängig stellt Eingabe und Bericht gemeinsam wieder her.
Heutige Zähler überschreiten den sicheren Ganzzahlbereich von JavaScript. Die Berechnung arbeitet ganzzahlig und exportiert genaue Zähler als JSON-Zeichenketten. So wird ein ungerades Enddigit nicht durch eine vorherige Gleitkommaumwandlung verloren.
Zunächst werden 11644473600000000 Mikrosekunden abgezogen. Danach erscheinen exakte Unix-Mikrosekunden sowie abgerundete Unix-Sekunden und Millisekunden mit eigenen Restfeldern. Aus Quotient und Mikrosekundenrest lässt sich der genaue Zeitpunkt wieder zusammensetzen.
Ein negativer WebKit-Wert liegt vor 1601, soweit das Datum im unterstützten Bereich liegt. Eine Mikrosekunde vor 1970 ergibt dagegen Unix-Sekunden -1 und den Rest 999999. Die Division rundet nach unten und schneidet nicht Richtung null ab.
Bis zu 1000 physische Zeilen und 100000 UTF-16-Einheiten sind zulässig. Die Ansicht beginnt mit 50 Zeilen und wächst um jeweils 50. Kopieren und Download enthalten stets alle Zeilen samt Original, Interpretation und Fehlertext.
Typische Quellen sind visits.visit_time und urls.last_visit_time in History sowie creation_utc oder expires_utc in Cookies. Prüfen Sie die jeweilige Datenbankversion und das Feld. Dieses Werkzeug liest die Dateien nicht selbst; es verarbeitet die eingefügten Einzelwerte.
Chromiums base::Time verwendet die Windows-Epoche 1601-01-01 UTC. Bis zum Unix-Anfang 1970 liegen 11644473600000000 Mikrosekunden dazwischen. Bloßes Teilen durch eine Million ändert die Einheit, korrigiert aber noch nicht den Zeitursprung.
Chromium kann mit null eine nicht initialisierte Zeit speichern. Rechnerisch ergibt sich 1601, doch das belegt kein Ereignis zu diesem Datum. possibleNull weist auf diesen Unterschied hin; die tatsächliche Bedeutung ergibt sich aus dem ursprünglichen Datensatz.
Wenn das Originalfeld Mikrosekunden ab 1601 enthält, den Dezimalwert in WebKit → Datum einfügen. Das UTC-Ergebnis zusammen mit dem Feldnamen lesen. Session-Cookies, Nullwerte oder abweichende API-Einheiten müssen anhand der Quelle eingeordnet werden.
Der Beginn ist gleich, die Einheit jedoch nicht: FILETIME zählt 100 Nanosekunden, Chrome hier Mikrosekunden. Der FILETIME-Zähler eines gewöhnlichen Zeitpunkts ist deshalb zehnmal so groß. Verwenden Sie den zur Einheit passenden Konverter.
Ein unerwartetes Ergebnis?
Sie können WebKit-Zeitstempel umrechnen und dabei eine bekannte Quellzeile gegenprüfen. Lesen Sie UTC-Datum, Sonderwerthinweis und Unix-Rest, bevor Sie den vollständigen Bericht speichern.