Convertissez des horodatages avec notre outil d'horodatage.
Qu'est-ce qu'un horodatage Unix ?
L'horodatage Unix compte les secondes depuis 1970.
C'est un moyen simple de stocker des dates.
Utilisé par les ordinateurs du monde entier.
L'instant 1970-01-01 00:00:00 UTC est l'époque Unix, et un horodatage est le nombre de secondes depuis cet instant. Une valeur comme 1787000000 correspond à un point précis de la frise.
En tant qu'entier simple, il ignore l'heure d'été, les secondes intercalaires et les changements de fuseaux. C'est pourquoi les systèmes, fichiers et API l'utilisent par défaut.
Pourquoi utiliser des horodatages ?
- Simple – Juste un nombre
- Universel – Fonctionne partout
- Pas de fuseaux – UTC par défaut
- Triable – Facile à comparer
- Compact – 4 ou 8 octets au lieu d'une chaîne de date
- Comparable – Des requêtes par plage sur un seul entier
- Indépendant du langage – La même valeur en JavaScript, Python, SQL et dans le shell
- Stable – L'époque ne bouge jamais, les anciennes valeurs restent valides
Usages courants
Stockage en base de données. Enregistrez les dates sous forme de nombres.
Réponses API. Compact et rapide.
Noms de fichiers. Triez facilement par date.
Mise en cache. Vérifiez si les données sont fraîches.
Journalisation. Préfixez les lignes de journal avec un horodatage Unix pour trier les événements entre services sans analyser des dates lisibles.
Expiration de session. Comparez émission et expiration comme des entiers, sans calcul de dates ni surprises d'heure d'été.
URLs signées et jetons. Les JWT portent des horodatages numériques (iat, exp, nbf) précisément parce qu'ils sont sans ambiguïté.
Temps Unix en 2026 : ce que tout développeur devrait savoir
Le temps Unix compte les secondes depuis le 01/01/1970 UTC et ignore les secondes intercalaires. Date.now() en JavaScript renvoie des millisecondes, donc normalisez toujours sur une seule unité avant de comparer des valeurs provenant de sources différentes.
Le problème de 2038 concerne toujours les systèmes 32 bits et les appareils embarqués ou IoT : le 19/01/2038 à 03:14:07 UTC, un compteur 32 bits signé déborde. Utilisez des valeurs de temps 64 bits ou des chaînes ISO-8601 pour tout ce qui doit survivre à cette date ; les serveurs et navigateurs modernes sont déjà sûrs en 64 bits.
La proposition Temporal du TC39 progresse régulièrement vers les navigateurs et rendra à terme les calculs de calendrier et de fuseaux horaires beaucoup plus sûrs. En attendant, conservez les horodatages en UTC, formatez-les avec Intl.DateTimeFormat et stockez le temps Unix pour les valeurs lisibles par machine. Vous pouvez convertir secondes et millisecondes avec notre convertisseur d'horodatage.
Les pièges de fuseaux apparaissent à la frontière du formatage, pas au stockage. Afficher 2026-08-17T09:00:00Z avec un analyseur naïf donne des valeurs locales différentes à Berlin, New York et Tokyo. Convertissez en heure locale uniquement à l'affichage.
Deux repères valent la peine d'être mémorisés : 1970-01-01 00:00:00 UTC est l'horodatage 0, et le 09/09/2001 à 01:46:40 UTC correspond à 1 000 000 000 – un bon test de vraisemblance.
FAQ
Q.Va-t-il s'épuiser ?
A.Le compteur tient jusqu'au 19/01/2038 sur les systèmes 32 bits signés ; les valeurs 64 bits restent valides environ 292 milliards d'années. Si votre code utilise encore un time_t 32 bits, prévoyez une migration : après cet instant, la valeur devient négative et les dates repassent à 1901.
Q.Secondes ou millisecondes ?
A.Le temps Unix est défini en secondes, mais les API s'accordent rarement. Date.now() et Date.parse() en JavaScript utilisent des millisecondes, time.time() en Python des secondes flottantes, et les pilotes SQL stockent l'un ou l'autre. Normalisez sur la même unité avant de comparer : divisez les millisecondes par 1000 ou multipliez les secondes par 1000, en arrondissant ou tronquant.
Q.Qu'est-ce que le problème de 2038 ?
A.Le 19/01/2038 à 03:14:07 UTC, un entier 32 bits signé ne peut plus contenir le temps Unix courant et déborde vers une valeur négative, lue comme décembre 1901. Les anciens noyaux, certains appareils embarqués et les formats 32 bits se comporteront mal ; les systèmes 64 bits ne sont pas concernés. Stockez les horodatages en entiers 64 bits ou en chaînes ISO-8601 en UTC.
Q.Horodatage Unix ou ISO 8601 – que stocker ?
A.Les deux fonctionnent, et de nombreux codebases les mélangent délibérément. Le temps Unix est compact (8 octets), indépendant du fuseau horaire et trivial à comparer, mais illisible d'un coup d'œil. L'ISO 8601 en UTC – par exemple 2026-08-17T14:30:00Z – se lit bien dans les journaux. Stockez l'instant en UTC, jamais en heure locale, et convertissez à la frontière avec Intl.DateTimeFormat.
Références
- RFC 3339 – Date and Time on the Internet : Horodatages : https://www.rfc-editor.org/rfc/rfc3339
- MDN – Date (JavaScript) : https://developer.mozilla.org/fr/docs/Web/JavaScript/Reference/Global_Objects/Date
- Temps Unix – Wikipédia : https://fr.wikipedia.org/wiki/Temps_Unix
Convertissez des horodatages localement
Convertissez des horodatages Unix en dates et inversement, en UTC et heure locale, entièrement dans votre navigateur.
Conclusion
Les bugs d'horodatage sont presque toujours des erreurs d'unité ou de fuseau horaire. Convertissez et comparez localement avec le convertisseur d'horodatage.
Ces deux erreurs se rattrapent facilement si vous normalisez tôt : convertissez secondes et millisecondes côte à côte avant de déboguer.