Date et heure
Une valeur Chrome par ligne, ou une date ISO avec Z ou un décalage explicite. Les dates obtenues sont en UTC.
Les données sont traitées dans ce navigateur et ne sont pas envoyées à un serveur.
Origine Chrome : 1601-01-01 UTC · une unité = une microseconde.
Un entier décimal signé par ligne, ou YYYY-MM-DDTHH:mm:ss[.1–6 chiffres]Z / ±HH:mm. Années UTC admises : 0001–9999.
Zéro a une date arithmétique, mais peut signifier « non défini » dans Chromium. Les extrêmes int64 sont des sentinelles infinies, sans date.
UTC affiche six décimales. Secondes et millisecondes Unix sont arrondies vers le bas, avec leurs restes positifs ou nuls en microsecondes.
Jusqu’à 1 000 lignes physiques et 100 000 unités UTF-16. Espaces en bordure retirés ; lignes vides signalées.
L’inversion exige une date pour chaque ligne. Vérifiez d’abord les erreurs et les sentinelles infinies.
Saisissez des données ou chargez un exemple.
Le Convertisseur WebKit sert à relire les grands entiers extraits de l’historique Chrome. Utilisez la valeur d’origine : si un tableur a déjà arrondi les derniers chiffres, la conversion ne pourra pas les retrouver.
Le nom WebKit désigne ici le format de base de données Chrome/Chromium compté depuis 1601. Des API du même navigateur peuvent utiliser une autre origine ou une autre unité. Le nom du champ et sa provenance comptent davantage que le nombre de chiffres.
Le Convertisseur WebKit transforme 11644473600000001 en 1970-01-01T00:00:00.000001Z. Le retour à l’entier conserve le dernier 1. Les six décimales permettent de distinguer ce qu’un affichage limité aux millisecondes masque.
Une ligne mal formée ne bloque pas les autres. Le texte original et le numéro de ligne physique restent associés à chaque résultat. La liste ne se décale donc pas lorsqu’une entrée échoue au milieu d’une colonne extraite.
visits.visit_time dans la base et lastVisitTime dans l’API d’extension ne sont pas équivalents. L’API utilise des millisecondes Unix. Un entier court peut être valide ici : sa longueur ne suffit pas à reconnaître un horodatage Chrome.
Le sens inverse exige Z ou ±HH:mm, même si votre ordinateur fonctionne en UTC. Exemple suit le sens choisi et ouvre un aperçu avant remplacement. Une fraction de plus de six chiffres provoque une erreur au lieu d’être tronquée.
Le mode automatique attend 350 ms après modification. Désactivez-le pour utiliser le bouton ou Ctrl/Cmd+Entrée. Toute modification bloque immédiatement l’export. Après application du sens inverse, Annuler restaure ensemble l’entrée et le rapport précédent.
Les compteurs actuels dépassent la limite des entiers sûrs de JavaScript. Le calcul utilise des entiers et le JSON conserve les compteurs précis sous forme de chaînes. Un passage préalable par un flottant pourrait perdre le dernier chiffre impair.
L’horodatage Unix en microsecondes s’obtient en retranchant 11644473600000000. Les secondes et millisecondes sont arrondies vers le bas, avec un reste distinct en microsecondes. Les champs permettent de reconstruire la valeur précise au lieu de confondre précision et unité d’affichage.
Un nombre WebKit négatif représente un instant antérieur à 1601 dans la plage admise. Une microseconde avant 1970 donne -1 seconde Unix avec un reste de 999999 microsecondes. La division ne tronque pas vers zéro.
La limite est de 1000 lignes physiques et 100000 unités UTF-16. L’affichage commence à 50 lignes et s’étend par groupes de 50. Copie et téléchargement comprennent toutes les lignes, leur texte original, leur interprétation et les erreurs éventuelles.
Le résultat est toujours en UTC. Dans le sens date vers entier, Z ou un décalage explicite est obligatoire. Ainsi, 1970-01-01T01:00:00+01:00 désigne l’origine Unix, quel que soit le réglage horaire de votre machine.
Oui, dans la plage de dates prise en charge. Un entier WebKit négatif correspond à une date avant 1601, tandis qu’un entier Unix négatif se situe avant 1970. Il faut donc garder l’origine choisie avec le résultat.
Vérifiez que le champ original, tel que creation_utc ou expires_utc, contient bien des microsecondes depuis 1601. Collez alors l’entier dans WebKit → date. Interprétez le résultat UTC avec le champ source, surtout en présence d’un zéro ou d’un état particulier.
L’origine est commune, mais pas l’unité : une microseconde ici, contre 100 nanosecondes pour FILETIME. Pour un instant ordinaire, le nombre FILETIME est dix fois plus grand. Utilisez le convertisseur correspondant à l’unité d’origine.
Chromium peut représenter une heure non initialisée par zéro. L’arithmétique donne 1601, sans prouver qu’un événement a eu lieu à cette date. L’avis possibleNull invite à vérifier le contexte ; le seul nombre ne permet pas de déduire le statut d’un cookie.
Un résultat inattendu ?
Revenez au Convertisseur WebKit avec une valeur source vérifiable. Comparez la date UTC, les avis particuliers et les restes Unix avant d’enregistrer le rapport complet.