Les sept erreurs qui produisent une date fausse
Un convertisseur epoch fait de l'arithmétique simple, donc quand la sortie est fausse, la cause n'est presque jamais le calcul — c'est l'entrée. Un timestamp ne porte aucune étiquette indiquant s'il est en secondes ou en millisecondes, en UTC ou en local, ou quelle est sa précision, et chaque conversion erronée vient d'une mauvaise supposition sur l'un de ces points. L'indice le plus rapide est l'année obtenue : une date près de 1970 ou des milliers d'années dans le futur est une confusion d'unité, et une date juste mais décalée d'un nombre rond d'heures est une erreur de fuseau. Le tableau ci-dessous est le guide de terrain ; les sections suivantes expliquent en profondeur les erreurs d'unité et de fuseau et montrent comment vérifier une conversion dans le code.
| Erreur | Ce que vous voyez | Cause | Correctif |
|---|---|---|---|
| Secondes lues comme millisecondes | La date tombe en 1970 | Date et Date.now() de JS attendent des ms ; vous avez passé des secondes à 10 chiffres | Multiplier les secondes par 1000 |
| Millisecondes lues comme secondes | Date des milliers d'années dans le futur | Valeur à 13 chiffres passée à une fonction en secondes | Diviser d'abord par 1000 |
| UTC affiché comme heure locale | Bon jour, horloge décalée de votre offset | Le convertisseur a choisi par défaut un autre fuseau | Régler le convertisseur sur UTC |
| Heure locale copiée sans son offset | Décalée de plusieurs heures sur une autre machine | Une heure murale stockée sans fuseau | Stocker l'UTC plus le fuseau |
| Heure murale ambiguë (heure d'été) | Décalée d'exactement une heure près d'un changement | Une heure locale qui survient deux fois ou jamais | Convertir depuis l'UTC ; fixer le fuseau IANA |
| Micro/nanosecondes lues comme secondes | Date loin dans le futur (16 ou 19 chiffres) | Valeur de base de données ou de traçage en µs ou ns | Diviser par 1 000 000 (µs) ou 1 000 000 000 (ns) |
| Faire confiance à la précision affichée | Partie infra-seconde silencieusement supprimée | Le convertisseur a tronqué les millisecondes | Confirmer l'unité documentée par l'API cible |
Ce que fait un convertisseur epoch
Un convertisseur epoch transforme des timestamps numériques en dates lisibles et reconvertit des dates humaines en timestamps epoch. Un bon convertisseur gère les secondes Unix, les millisecondes Unix, la sortie UTC, la sortie en fuseau local et les chaînes ISO 8601, et il rend l'unité évidente avant que vous ne copiiez une valeur dans du code, une base de données ou une requête d'API. Convertisseur epoch, convertisseur d'heure Unix, convertisseur de timestamp Unix et calculateur d'epoch Unix décrivent tous le même travail : traduire entre un décompte de secondes (ou de millisecondes) depuis le 1er janvier 1970 UTC et une date lisible par un humain. Le convertisseur est rarement le problème — c'est généralement l'entrée.
Les erreurs d'unité : secondes, millisecondes, micro, nano
L'erreur de conversion la plus fréquente de loin est une confusion d'unité, et elle a une signature : la date tombe en 1970 ou à des milliers d'années. JavaScript est l'endroit où elle frappe le plus souvent, car le constructeur Date et Date.now() travaillent tous deux en millisecondes alors que la plupart des API, bases de données et la commande Unix date travaillent en secondes. Passez une valeur en secondes à 10 chiffres à new Date() sans multiplier par 1000 et vous atterrissez 53 ans trop tôt. L'inverse — alimenter une fonction en secondes avec des millisecondes à 13 chiffres — projette la date loin dans le futur. Les sources de plus haute précision aggravent les choses : les bases de données émettent souvent des microsecondes à 16 chiffres et les systèmes de traçage des nanosecondes à 19 chiffres, et les deux ressemblent à une valeur Unix valide jusqu'à ce qu'elles se décodent dans le mauvais millénaire.
- 10 chiffres → secondes (p. ex. 1700000000) ; 13 → millisecondes ; 16 → microsecondes ; 19 → nanosecondes
- JavaScript : new Date(seconds * 1000), ou new Date(ms) directement
- Microsecondes → diviser par 1 000 000 avant la conversion ; nanosecondes → par 1 000 000 000
- Vérification de bon sens : le résultat doit être une date plausible dans la décennie actuelle
Les erreurs de fuseau : UTC vs local et heure d'été
Une fois l'unité correcte, les erreurs restantes sont des erreurs de fuseau, et elles partagent aussi une signature : la date est correcte mais l'horloge est décalée d'un nombre entier d'heures. Un timestamp Unix est un instant unique sans fuseau propre ; l'offset n'est appliqué qu'au moment de formater l'instant. Deux convertisseurs réglés sur des fuseaux différents affichent donc des heures différentes pour le même nombre — aucun n'a tort, ils montrent simplement des vues locales différentes. Le piège est de copier une heure murale locale sans noter de quel fuseau elle vient, ou de convertir une heure qui tombe sur un changement d'heure d'été, où une heure locale peut survenir deux fois ou pas du tout. Quand un résultat est décalé d'exactement une heure, soupçonnez l'heure d'été avant de soupçonner le convertisseur.
- Comparer les valeurs en UTC ; n'appliquer un fuseau local qu'au moment de les afficher
- Ne jamais stocker une heure locale sans aussi stocker son fuseau IANA ou son offset UTC
- Autour d'un changement d'heure d'été, dériver l'instant de l'UTC, pas d'une heure locale ambiguë
Choisir d'abord le sens
La plupart des tâches de timestamp vont dans l'un de deux sens : epoch vers date, ou date vers epoch. Décider du sens en premier prévient la cause la plus fréquente de données de test fausses et de payloads d'API cassés — convertir la bonne valeur dans le mauvais sens.
- Epoch vers date : coller 1700000000 et lire la date UTC ou locale
- Date vers epoch : choisir 2026-01-01 00:00:00 UTC et obtenir 1767225600
- Confirmer si la cible attend des secondes ou des millisecondes avant de copier le résultat
Ce qu'il faut vérifier avant de copier une valeur convertie
Un convertisseur ne peut être correct que dans la mesure où l'entrée est sans ambiguïté. Avant de copier un timestamp dans un test, un cron, une migration ou une requête d'API, confirmez l'unité, le fuseau et la précision attendue. La vérification de bon sens la plus rapide est l'année obtenue : une date près de 1970 ou loin dans le futur signale presque toujours une confusion d'unité plutôt qu'une erreur du convertisseur.
- Le système destinataire attend-il des secondes ou des millisecondes ?
- La date affichée est-elle en UTC ou en heure locale ?
- Le timestamp représente-t-il un instant ou une date calendaire locale ?
- La colonne de base de données stocke-t-elle un datetime natif, des secondes Unix ou des millisecondes Unix ?
- Le résultat est-il près de 1970 ou loin dans le futur, ce qui signale généralement une confusion d'unité ?
Vérifier une conversion dans le code
Quand une valeur convertie compte — une migration, une limite de facturation, un planning cron — ne faites pas confiance à un seul outil. Redérivez le même instant dans votre propre runtime et vérifiez que les deux concordent en UTC. Chacune de ces lignes imprime une chaîne ISO 8601 sans ambiguïté avec un suffixe Z, il n'y a donc aucune devinette de fuseau local à comparer.
- JavaScript : new Date(1700000000 * 1000).toISOString() // '2023-11-14T22:13:20.000Z'
- Python : datetime.fromtimestamp(1700000000, tz=timezone.utc).isoformat()
- Shell (GNU) : date -u -d @1700000000 +'%Y-%m-%dT%H:%M:%SZ'
- Si l'outil et votre runtime divergent, l'unité ou le fuseau de l'entrée est le suspect — pas le convertisseur
Exemple concret : un instant, trois représentations
Prenez l'instant 2026-01-01 00:00:00 UTC. En secondes Unix, c'est 1767225600 ; en millisecondes Unix, 1767225600000 ; en ISO 8601, c'est 2026-01-01T00:00:00Z. Les trois décrivent le même moment — seuls le format et l'unité diffèrent. L'instant ne porte jamais de fuseau propre ; New York afficherait cette même valeur comme 2025-12-31 19:00:00, car l'offset est appliqué au moment de l'affichage, pas stocké dans le nombre.
Articles associés
FAQ
- Pourquoi ma date convertie tombe-t-elle en 1970 ?
- Presque toujours parce que des secondes ont été lues comme des millisecondes. Date et Date.now() de JavaScript utilisent des millisecondes, donc passer une valeur en secondes à 10 chiffres tombe en janvier 1970. Multipliez d'abord les secondes par 1000.
- Pourquoi mon heure convertie est-elle décalée d'exactement une heure ?
- C'est une erreur de fuseau horaire ou d'heure d'été, pas une erreur de calcul. Le convertisseur a appliqué un autre fuseau, ou l'heure locale tombait sur un changement d'heure. Réglez le convertisseur sur UTC pour voir l'instant canonique, puis appliquez le fuseau que vous voulez réellement.
- Quel est le meilleur format de convertisseur epoch à copier ?
- Pour le code, copiez des secondes ou des millisecondes Unix selon ce que documente l'API cible. Pour les humains, copiez de l'ISO 8601 avec un Z ou un décalage de fuseau explicite afin que l'instant soit sans ambiguïté.
- Un convertisseur epoch est-il la même chose qu'un convertisseur d'heure Unix ?
- Pour la plupart des recherches de développeurs, oui. Convertisseur epoch, convertisseur d'heure Unix, convertisseur de timestamp Unix et calculateur d'epoch Unix convertissent tous entre des timestamps d'epoch Unix et des dates lisibles.
- Pourquoi les convertisseurs epoch affichent-ils des heures locales différentes ?
- Ils appliquent des fuseaux différents. L'instant UTC sous-jacent est identique ; seul l'affichage local change. Réglez le convertisseur sur UTC pour comparer la valeur canonique.
- Comment savoir si mon nombre est en secondes ou en millisecondes ?
- Comptez les chiffres. Une valeur moderne à 10 chiffres est en secondes Unix ; une valeur à 13 chiffres est en millisecondes Unix. Si une valeur à 10 chiffres tombe près de 1970 en JavaScript, elle a été traitée comme des millisecondes et doit être multipliée par 1000.