Nanosecondes vers date
Convertissez des nanosecondes en date lisible. Saisissez l'horodatage en nanosecondes (par ex. 1704067200000000000).
Un horodatage en nanosecondes perd silencieusement ses trois derniers chiffres dans un nombre JavaScript
Les nombres JavaScript ne contiennent exactement les entiers que jusqu'à 2⁵³ − 1. Un horodatage actuel en nanosecondes vaut environ 1,77 × 10¹⁸, soit 196 fois cette limite. Fournissez-en un et 1770000000123456789 revient sous la forme 1770000000123456800 : aucune erreur, aucun avertissement, simplement trois chiffres remplacés en silence.
Comment ça marche
- Convertit des horodatages en nanosecondes en dates et inversement, en conservant la partie inférieure à la milliseconde.
- Signale la limite de précision, car cette défaillance est silencieuse et non bruyante.
- Gère la conversion en millisecondes que la plupart des bibliothèques de dates exigent en entrée.
nanosecondes ÷ 1 000 000 = millisecondes nanosecondes ÷ 1 000 000 000 = secondes MAX_SAFE_INTEGER = 9 007 199 254 740 991 (2⁵³ − 1) en nanosecondes, toute cette plage ne couvre que ~104 jours en millisecondes, elle couvre ~285 000 ans
Exemple chiffré
Ce que chaque unité de temps couvre dans la plage d'entiers sûrs, et ce qui arrive au-delà.
- millisecondes : 2⁵³ couvre environ 285 000 ans
- microsecondes : environ 285 ans
- nanosecondes : environ 0,285 an — à peu près 104 jours
- 1770000000123456789 affecté à un nombre
- se relit comme 1770000000123456800
Les trois derniers chiffres ont changé et rien ne l'a signalé. Un horodatage en nanosecondes exige un BigInt ou une chaîne ; le stocker dans un nombre ordinaire n'est pas un désagrément d'arrondi mais la garantie que tout détail sous la microseconde est une fiction.
Lire le résultat
- Utilisez BigInt pour l'arithmétique en nanosecondes et ne convertissez en nombre qu'après avoir divisé jusqu'aux millisecondes. La division doit se faire dans l'espace BigInt : convertir d'abord et diviser ensuite a déjà détruit les chiffres que vous vouliez garder.
- Bases de données et formats de transport véhiculent souvent les nanosecondes sous forme de chaînes pour exactement cette raison. Parser une telle chaîne en flottant pour « faire propre » est la façon la plus courante de perdre la précision, et cela se produit dans la couche que personne n'inspecte.
- L'objet Date de JavaScript est lui-même fondé sur la milliseconde et ne peut pas représenter de temps plus fin. Convertir des nanosecondes en Date écarte le reste par conception : la perte y est attendue et non fautive — la surprise ne vient que lorsqu'elle survient silencieusement pendant un calcul.
- La précision à la nanoseconde est rarement le vrai besoin. Tri des journaux, traçage et profilage réclament en général un ordre monotone plutôt qu'une exactitude absolue à la nanoseconde, et une horloge monotone le fournit sans le problème de représentation.
Questions fréquentes
- Pourquoi mon horodatage a-t-il changé de quelques centaines de nanosecondes ?
- Il a été stocké dans un nombre à virgule flottante incapable de le représenter. Au-delà de 2⁵³ − 1, les entiers sont arrondis à la valeur représentable la plus proche : 1770000000123456789 devient donc 1770000000123456800. Rien ne lève d'erreur, car c'est un comportement défini et non un défaut.
- Comment stocker des horodatages en nanosecondes ?
- En BigInt en JavaScript, en entier 64 bits dans la plupart des autres langages, ou en chaîne au passage d'une frontière comme JSON. Ne convertissez en nombre qu'après avoir divisé jusqu'aux millisecondes et n'avoir plus besoin des chiffres supplémentaires.