Convertisseur de timestamp Unix

Les horodatages Unix sans prise de tête

Demandez l'heure à trois développeurs et vous pourriez obtenir trois réponses, selon l'endroit où ils se trouvent. Demandez-la à un horodatage Unix et vous obtenez exactement un nombre, le même pour tout le monde sur la planète. Cet entier unique est la raison pour laquelle le temps epoch sous-tend discrètement presque chaque fichier de logs, ligne de base de données et réponse d'API que vous toucherez jamais. Cette page explique ce que signifie ce nombre, comment le lire dans les deux sens, et où il a tendance à piéger les gens.

Ce qu'est réellement le temps Unix

Un horodatage Unix est le nombre de secondes écoulées depuis 00:00:00 UTC le 1er janvier 1970, sans compter les secondes intercalaires. Ce moment est appelé l'epoch, et il a été choisi par les premiers ingénieurs Unix simplement parce que c'était une date ronde commode à partir de laquelle compter. À l'epoch, la valeur vaut exactement 0. Chaque seconde écoulée depuis ajoute un, le nombre ne fait donc que croître. Les dates antérieures à 1970 sont parfaitement valides elles aussi, exprimées sous forme d'entiers négatifs.

Vous verrez aussi ce concept appelé temps POSIX ou, de manière relâchée, temps epoch. Quelle que soit l'étiquette, le mécanisme est le même : un compteur unique de secondes en perpétuelle augmentation. Comme c'est un simple entier plutôt qu'une chaîne formatée, un ordinateur peut le stocker en quelques octets et comparer deux valeurs avec une seule soustraction.

Secondes, millisecondes et compagnie

Le temps Unix classique compte des secondes entières, ce qui donne le fameux nombre à dix chiffres que vous voyez aujourd'hui. Mais beaucoup d'environnements ont besoin d'une résolution plus fine. JavaScript, par exemple, travaille en millisecondes, produisant une valeur à treize chiffres, et certains systèmes vont plus loin jusqu'aux microsecondes ou nanosecondes. Une règle empirique fiable : un nombre à dix chiffres représente des secondes, treize chiffres des millisecondes. Si votre date convertie atterrit autour de 1970 alors que vous attendiez l'époque actuelle, vous avez presque certainement injecté des millisecondes dans un champ de secondes, ou l'inverse. Notre convertisseur détecte automatiquement l'ordre de grandeur, vous avez donc rarement à deviner.

Pourquoi les développeurs s'appuient dessus

Le grand avantage, c'est qu'un horodatage est neutre vis-à-vis du fuseau horaire. L'entier 1735689600 désigne le même instant à Tokyo, Berlin et São Paulo. Stocker ce nombre plutôt qu'une chaîne locale formatée signifie que vous n'avez jamais à vous demander à quelle horloge une valeur appartenait. Le tri est tout aussi trivial, car l'ordre chronologique n'est que l'ordre numérique, de sorte qu'un index de base de données sur une colonne d'horodatage trie les événements correctement sans aucune analyse. L'arithmétique est tout aussi propre : l'écart entre deux événements est une soustraction, et ajouter un jour revient à ajouter 86400. Ces propriétés sont précisément pourquoi les logs, les jetons, les caches et les files de messages recourent tous au temps epoch.

Convertir dans les deux sens

Passer d'un horodatage à une date humaine revient à prendre le compte de secondes et à le projeter sur un calendrier, puis à formater le tout dans le fuseau horaire qui vous importe. Dans l'autre sens, vous prenez une année, un mois, un jour et une heure, décidez dans quel fuseau ils sont exprimés, et ramenez le tout à des secondes depuis l'epoch. Notre outil fait les deux directions instantanément et entièrement dans votre navigateur, donc rien de ce que vous collez ne quitte votre machine. Collez un nombre pour le décoder, ou choisissez une date pour l'encoder, et lisez le résultat à la fois en UTC et dans votre heure locale au même instant.

UTC versus heure locale, le piège classique

L'horodatage en lui-même n'a pas de fuseau horaire ; il est toujours ancré à l'UTC. La confusion n'apparaît qu'au moment où vous l'affichez. Si vous convertissez 1700000000 et que votre écran montre une heure du soir tandis qu'un collègue dans un autre pays voit l'après-midi, rien n'est cassé : vous regardez tous deux le même instant rendu sur des horloges locales différentes. Les bugs s'insinuent quand du code lit une date locale comme si elle était en UTC, ou estampille une heure murale sans noter le décalage. La bonne habitude est de stocker et transmettre l'UTC, et de n'appliquer un décalage local qu'au tout dernier moment, lorsque vous montrez la valeur à une personne. En cas de doute, comparez à la ligne UTC du convertisseur plutôt qu'à votre ligne locale.

Le problème de l'an 2038

Beaucoup de systèmes anciens stockaient le temps Unix dans un entier signé de 32 bits. Ce champ arrive à court de place une seconde après 03:14:07 UTC le 19 janvier 2038, lorsque le compteur déborde et bascule vers un nombre négatif, renvoyant potentiellement les dates en 1901. C'est la même famille de problèmes que le bug de l'an 2000. La bonne nouvelle, c'est que les systèmes d'exploitation et les langages modernes sont largement passés à des horodatages sur 64 bits, qui ne déborderont pas avant environ 292 milliards d'années ; pour du code neuf, c'est donc surtout une curiosité historique bonne à connaître plutôt qu'une urgence.

Pour davantage d'aides fonctionnant dans le navigateur, consultez nos outils pour développeurs, et si vous devez manipuler les nombres eux-mêmes, les calculatrices ne sont qu'à un clic.

Questions fréquentes