Convertisseur d'horodatage Unix
Horodatages des dates et retours, avec l'unité élaborée pour vous et indiquée.
Laissez vide pour voir l’heure actuelle. Un nombre seul est lu comme un horodatage Unix.
Compter les chiffres
La seule chose vraiment délicate quand on lit un horodatage, c’est d’en déterminer l’unité — et l’ordre de grandeur tranche. En pratique il n’y a aucune ambiguïté, car les plages ne se recouvrent pour aucune date sur laquelle quelqu’un travaille réellement.
| Chiffres | Unité | Exemple | D’où cela vient |
|---|---|---|---|
| 10 | Secondes | 1787788800 | Unix, PHP, la plupart des API, les claims JWT |
| 13 | Millisecondes | 1787788800000 | JavaScript, Java, Kafka |
| 16 | Microsecondes | 1787788800000000 | time_ns()/1000 en Python, les entrailles de Postgres |
| 19 | Nanosecondes | 1787788800000000000 | Go, InfluxDB, Prometheus |
Se tromper, c’est se tromper d’un facteur mille : le résultat atterrit soit au début des années 1970, soit des dizaines de milliers d’années dans le futur. Évident quand on le regarde ; totalement invisible quand ce n’est qu’une colonne parmi d’autres dans une table de journaux — et c’est bien là que cela mord.
Ce que compte réellement le temps Unix
Des secondes depuis le 1er janvier 1970 à 00:00:00 UTC, en supposant que chaque jour dure exactement 86 400 secondes.
Cette hypothèse est fausse. Des secondes intercalaires sont insérées tous les quelques années pour garder le temps atomique aligné sur la rotation de la Terre, qui ralentit peu à peu. Le temps Unix ne les représente pas : les systèmes répètent une seconde, ou l’étalent sur une journée, afin que le compte reste uniforme.
La conséquence, c’est que le temps Unix n’est pas un décompte exact des secondes écoulées depuis 1970 : il est court d’environ vingt-sept secondes. Pour la planification, la journalisation et les expirations, c’est exactement le bon compromis, car l’arithmétique uniforme importe plus que l’exactitude astronomique. Pour tout ce qui mesure une durée réellement écoulée, utilisez plutôt une horloge monotone : l’horloge murale peut aussi reculer quand NTP la corrige.
Le problème de 2038
Un entier signé sur 32 bits va jusqu’à 2 147 483 647, ce qui, en horodatage Unix, correspond au 19 janvier 2038 à 03:14:07 UTC. Une seconde plus tard, il déborde en négatif et la date devient décembre 1901.
Tout ce qui est moderne utilise 64 bits et tient environ 292 milliards d’années. Ce qui ne l’est pas : les micrologiciels embarqués, les automates industriels, certains types de colonnes de bases de données anciennes, et le code C qui suppose encore un time_t sur 32 bits. Les systèmes les plus exposés sont ceux que personne ne regarde — c’est aussi ce qui a rendu le bug de l’an 2000 si coûteux.
Quel format employer, concrètement
ISO 8601 en UTC, pour tout ce qui franchit une frontière entre systèmes ou sera lu par un humain :
2026-08-27T14:30:00ZIl est sans ambiguïté, il se trie correctement en tant que simple chaîne, et il reste lisible dans un journal à deux heures du matin. Le Z compte : sans lui, la plupart des analyseurs supposent l’heure locale, et vous venez d’inventer un bug qui ne se manifeste que pour les utilisateurs d’autres pays.
Les secondes Unix conviennent en interne — c’est ce qu’emploient les claims exp et iat d’un JWT, et comparer des entiers ne coûte rien. Leurs défauts : elles sont illisibles, et elles invitent à la confusion d’unités décrite plus haut.
À éviter : tout format comportant un décalage mais aucun identifiant de zone (+01:00 ne vous dit pas s’il s’agit de BST ou de CET, ce qui compte pour les dates futures), et tout ce qui ressemble à 03/04/2026, qui désigne deux jours différents selon le côté de l’Atlantique où on le lit.
Enregistrer des événements futurs
Une subtilité qui prend les gens au dépourvu. Pour une réunion à 09:00 en mars prochain, enregistrer de l’UTC est faux : si les règles de fuseau changent d’ici là — et les gouvernements les changent — la réunion se déplace. Les événements locaux futurs doivent être enregistrés comme une heure locale accompagnée d’un identifiant de zone (Europe/London), puis convertis à l’affichage avec les règles alors en vigueur. Les événements passés, c’est l’inverse : de l’UTC, parce que ce qui s’est produit est figé.
À voir aussi
Les claims exp et iat d’un JWT sont des secondes Unix — le décodeur de JWT les convertit pour vous et signale l’expiration. Pour planifier plutôt que convertir, l’analyseur cron montre quand une planification se déclenchera la prochaine fois.
Questions sur les horodatages
Mon horodatage est-il en secondes ou en millisecondes ?
Comptez les chiffres. Un horodatage actuel en secondes comporte 10 chiffres et le restera jusqu'en novembre 2286 ; en millisecondes, c'est 13. Seize chiffres correspondent à des microsecondes et dix-neuf à des nanosecondes. Se tromper multiplie par mille la réponse, ce qui vous amène soit juste après 1970, soit quelque part en l'an 56 000 – évident une fois que vous regardez, invisible dans un journal. Le convertisseur indique quelle unité il a prise et vous permet de la remplacer.
Quel est le problème de l’année 2038 ?
Systèmes qui stockent l'heure Unix dans un débordement d'entier signé de 32 bits le 19 janvier 2038, jusqu'en décembre 1901. Tout ce qui est moderne utilise 64 bits et fonctionne pendant environ 292 milliards d'années. Ce qui ne va pas, ce sont les micrologiciels intégrés, les anciennes bases de données, certains formats de système de fichiers et tout code C utilisant encore un time_t 32 bits. Il s’agit d’un problème du même type que celui de l’an 2000 et, comme l’an 2000, il sera généralement traité discrètement à l’avance par des personnes dont vous n’entendez jamais parler.
Pourquoi les horodatages ignorent-ils les secondes intercalaires ?
Parce que le temps Unix est défini comme le nombre de secondes depuis que l'époque supposant que chaque jour est exactement de 86 400 secondes – ce qui n'est pas vrai, puisque des secondes intercalaires sont insérées occasionnellement pour maintenir les horloges alignées sur la rotation de la Terre. Plutôt que de les représenter, la plupart des systèmes répètent ou étalent une seconde pour que le décompte reste ordonné. Cela signifie que le temps Unix n'est pas un véritable décompte des secondes écoulées et que, dans presque tous les cas, c'est le bon échange.
Quel format dois-je utiliser dans une API ?
ISO 8601 en UTC, avec le suffixe Z : 2026-08-27T14:30:00Z. Il est sans ambiguïté, trie correctement sous forme de chaîne et est lisible par une personne déboguant un journal à deux heures du matin. Les secondes Unix conviennent en interne et sont ce que JWT prétend utiliser, mais elles sont opaques à lire et invitent à la confusion entre secondes et millisecondes ci-dessus. Ce qu'il faut éviter, c'est tout format avec un décalage local mais pas de zone, et tout ce qui est en territoire JJ/MM versus MM/JJ.
Pourquoi ma date affiche-t-elle un jour différent de celui prévu ?
Presque toujours une limite de fuseau horaire. Une chaîne ISO sans zone est interprétée comme l'heure locale par la plupart des analyseurs, tandis qu'une chaîne se terminant par Z est UTC — donc un horodatage tard dans la soirée à Londres est déjà le lendemain en UTC, et un horodatage tôt le matin à Los Angeles est toujours le jour précédent. Stocker et transmettre en UTC ; convertissez uniquement lorsque vous affichez.
Dernière vérification . Vous avez repéré quelque chose de dépassé ? Dites-le-nous.