Dev · 4 min de lecture ·
Timestamps Unix : secondes ou millisecondes ?
Le bug des 13 chiffres qui part en production chaque semaine, et une règle toute simple pour distinguer les deux unités.
JavaScript compte en millisecondes, la plupart des backends en secondes. Confondez les deux et vos dates atterrissent en janvier 1970, ou des dizaines de milliers d’années dans le futur.
Comptez les chiffres
Un timestamp actuel en secondes compte 10 chiffres (1790000000 correspond au 21 septembre 2026). Le même instant compte 13 chiffres en millisecondes, 16 en microsecondes et 19 en nanosecondes.
La règle
Si la valeur absolue dépasse 10¹², ce sont des millisecondes ; sinon, traitez-la comme des secondes. La règle vaut pour tout timestamp en millisecondes postérieur à septembre 2001 et tout timestamp en secondes antérieur à l’an 33658.
const ms = Math.abs(n) > 1e12 ? n : n * 1000;Un horodatage n’a pas de fuseau horaire
Un horodatage Unix compte les secondes écoulées depuis le 1er janvier 1970 à 00:00 UTC. Le même nombre désigne le même instant partout dans le monde ; seule la manière de l’afficher change. Les bugs apparaissent quand une heure locale est convertie en horodatage comme si c’était de l’UTC : toutes les dates se décalent de votre fuseau, souvent d’une ou deux heures, et encore aux changements d’heure. Stockez et transmettez les horodatages en UTC, et ne convertissez en heure locale qu’au moment de les afficher à une personne.
Obtenir l’heure actuelle dans les langages courants
JavaScript Date.now() millisecondes
JavaScript Math.floor(Date.now() / 1000) secondes
Python time.time() secondes (avec décimales)
Java System.currentTimeMillis() millisecondes
Go time.Now().Unix() secondes
PostgreSQL EXTRACT(EPOCH FROM now()) secondes
MySQL UNIX_TIMESTAMP() secondesLes dates avant 1970 et l’an 2038
Les horodatages négatifs sont valides : −86400 correspond au 31 décembre 1969. Certains anciens systèmes et tableurs ne les gèrent pas, c’est pourquoi les dates de naissance et les données historiques sont une source fréquente de bugs. À l’autre bout, un entier signé de 32 bits s’arrête à 2147483647, soit le 19 janvier 2038 à 03:14:07 UTC. Les systèmes qui stockent encore les horodatages sur 32 bits reviendront à 1901 ; le stockage sur 64 bits règle le problème pour des milliards d’années.
Les secondes intercalaires
Le temps Unix ignore les secondes intercalaires : chaque jour compte exactement 86 400 secondes. Cela garde des calculs simples, et pour presque toutes les applications la différence est sans importance. Seuls les systèmes qui ont besoin d’intervalles précis au moment d’une seconde intercalaire, comme certains systèmes scientifiques ou financiers, doivent s’en soucier.
Une liste rapide pour déboguer
- La date tombe en janvier 1970 : une valeur en secondes a été lue comme des millisecondes.
- L’année compte cinq chiffres : une valeur en millisecondes a été lue comme des secondes.
- Toutes les dates sont décalées du même nombre d’heures : l’heure locale a été traitée comme de l’UTC, ou l’inverse.
- Les dates sont décalées d’une heure une partie de l’année : un changement d’heure a été ignoré.
- Les dates sautent à 1901 : un dépassement de capacité sur 32 bits.
Choisissez l’unité explicitement
Le convertisseur de timestamps de 4Dev ne devine pas : "Unix Timestamp" signifie secondes et "Unix Timestamp (ms)" millisecondes, à côté de variantes en microsecondes et nanosecondes. Il propose 33 formats au total, dont ISO 8601, RFC 2822, SQL DATETIME et les dates série d’Excel.
ISO 8601 quand des personnes lisent la date
Les horodatages sont parfaits pour le stockage et les calculs, mais difficiles à lire. Dans les logs, les API et les fichiers que des personnes ouvrent, l’ISO 8601, comme 2026-09-21T14:30:00Z, est sans ambiguïté, se trie correctement comme du texte et indique explicitement le fuseau horaire. Passer de l’un à l’autre, c’est précisément le rôle du convertisseur d’horodatages.