Un horodatage Unix est un simple nombre : combien de secondes se sont écoulées depuis minuit UTC le 1er janvier 1970. C'est toute la conception, et cette économie explique qu'on le trouve partout — journaux, bases de données, JWT, API. Elle explique aussi pourquoi un outil est nécessaire : un nombre comme 1752537600 ne dit strictement rien à un humain.
Secondes ou millisecondes : le facteur 1000
Le temps Unix compte des secondes. JavaScript compte des millisecondes — Date.now() renvoie un nombre mille fois plus grand, et tous les constructeurs Date de JavaScript aussi. Ce décalage est responsable de plus d'horodatages cassés que tout le reste réuni.
Le symptôme est reconnaissable une fois qu'on le connaît. Donnez une valeur en secondes à quelque chose qui attend des millisecondes et vous atterrissez en janvier 1970 : tout l'intervalle du temps Unix jusqu'ici se réduit à trois semaines. Donnez des millisecondes là où des secondes sont attendues et vous obtenez une date dans cinquante mille ans. Aucun ne lève d'erreur. Les deux s'affichent gaiement comme une date, et c'est ce qui fait survivre le bug à la revue de code.
Une vérification rapide : un horodatage actuel en secondes a dix chiffres, en millisecondes treize. Si vous fixez un nombre sans savoir, comptez les chiffres avant de diviser.
Un horodatage n'a pas de fuseau horaire
Cela vaut la peine de l'intérioriser, car cela dissout l'essentiel de la confusion sur les fuseaux. Un horodatage Unix est un instant — le même moment pour tout être vivant. Il n'est pas plus en UTC qu'à l'heure de Tokyo ; il est, simplement. Les fuseaux n'interviennent que lorsque vous restituez cet instant sous forme de date lisible, et c'est une décision d'affichage, pas une propriété de la donnée.
Ainsi « convertir cet horodatage en UTC » n'est pas du tout une conversion — c'est un choix de formatage. Le sélecteur de fuseau ici change la manière dont le même instant est écrit, pas ce qu'il signifie. C'est aussi pourquoi stocker des horodatages plutôt que des chaînes de date locale épargne tant de souffrance : un instant est sans ambiguïté, « 2025-10-26 02:30 » ne l'est pas.
Le problème de l'an 2038 est réel et mord déjà
Pendant des décennies, les systèmes Unix ont stocké le temps dans un entier signé 32 bits. Celui-ci s'épuise à 2147483647 secondes, soit 03:14:07 UTC le 19 janvier 2038. Une seconde plus tard la valeur déborde, bascule dans le négatif, et la date devient le 13 décembre 1901.
Cela semble lointain et ne l'est pas. Tout système calculant une date à plus de quelques années franchit déjà la ligne : un prêt sur trente ans, l'expiration d'un certificat, une projection de retraite. Des bugs de ce type étaient trouvés en production bien avant 2020. La plupart des plateformes modernes sont passées au temps 64 bits — ce qui repousse la limite au-delà de la durée de vie attendue du Soleil — mais les appareils embarqués, les vieux formats de fichiers et certaines colonnes de bases de données non. Si vous stockez aujourd'hui un horodatage dans une colonne 32 bits, c'est un bug avec une date d'échéance.
Le temps Unix ignore délibérément les secondes intercalaires
Voici un fait qui surprend même des développeurs chevronnés : un horodatage Unix n'est pas un vrai décompte des secondes écoulées. Depuis 1972, le monde a inséré 27 secondes intercalaires pour garder les horloges alignées sur la rotation de la Terre, et le temps Unix les saute toutes. Il définit chaque jour comme exactement 86400 secondes, que ce jour ait réellement compté 86400 secondes ou non.
Le compromis est délibéré. Il rend l'arithmétique triviale — toute date se convertit en horodatage par une simple division — au prix d'un décompte légèrement faux au sens absolu. Il signifie aussi que la vraie seconde intercalaire 23:59:60 n'est tout bonnement pas exprimable : JavaScript la rejette net, et Date.parse("2016-12-31T23:59:60Z") renvoie NaN alors même que cette seconde a bel et bien existé. S'il vous faut le temps réellement écoulé à travers les secondes intercalaires, le temps Unix est le mauvais instrument ; pour les 99,99 % restants du logiciel, ce compromis est exactement le bon.
Heures locales ambiguës et impossibles
Les horodatages sont nets ; les heures locales non. Deux fois par an, l'heure d'été fait dérailler l'heure de l'horloge murale. Quand les pendules reculent à Rome le dernier dimanche d'octobre, 02:30 se produit deux fois — une heure locale « 2025-10-26 02:30 » correspond à deux instants différents et rien dans la chaîne ne dit lequel. Quand les pendules avancent en mars, 02:30 n'existe pas du tout.
C'est pourquoi convertir une date locale en horodatage perd réellement de l'information, là où l'inverse n'en perd jamais. Si vous stockez des rendez-vous, des entrées de journal, tout ce dont l'instant exact compte, stockez l'horodatage et restituez l'heure locale à la sortie — pas l'inverse.
Questions fréquentes
Mes données sont-elles envoyées à un serveur ?
Non. Cet outil porte la mention « client » : la conversion est de l'arithmétique et du formatage effectués dans votre onglet, avec sa propre base de fuseaux horaires. Rien n'est transmis.
Mon horodatage affiche 1970. Qu'est-ce qui a mal tourné ?
Quelque chose a lu des secondes comme des millisecondes. Multipliez par 1000 et la date reprendra du sens. Cela signifie généralement qu'une valeur correcte en base a été passée telle quelle à un constructeur Date de JavaScript sans conversion — Date attend des millisecondes et ne vous préviendra pas.
Un horodatage peut-il être négatif ?
Oui — cela veut simplement dire avant 1970. Un horodatage de -1 correspond au 31 décembre 1969 à 23:59:59 UTC. La plupart des logiciels le gèrent correctement, mais pas tous : les champs de date de naissance pour les personnes nées avant 1970 ont historiquement été une riche source de bugs dans les systèmes dont les auteurs supposaient les horodatages toujours positifs.
Pourquoi le même horodatage affiche-t-il une autre heure sur l'écran de mon collègue ?
Parce que vous êtes dans des fuseaux différents, et c'est le comportement correct, pas un bug. L'instant est identique ; seule sa restitution diffère. Si tout le monde doit lire la même heure d'horloge — une fenêtre de maintenance planifiée, par exemple — indiquez explicitement le fuseau à côté, ou utilisez UTC et dites-le.
Dois-je stocker les dates en horodatages ou en chaînes ?
Stockez l'instant, que ce soit en horodatage entier ou dans une vraie colonne horodatage-avec-fuseau — votre base en a presque certainement une, et elle gérera des intervalles et une arithmétique qu'un entier nu ne peut pas. Ce qu'il faut éviter, c'est une chaîne de date locale sans fuseau : elle est ambiguë deux fois par an aux bascules d'heure d'été, et l'information manquante est irrécupérable ensuite.