Les timestamps Unix expliqués : époque, précision et le problème de l'an 2038

Un timestamp Unix est un entier unique qui ancre un instant dans le temps. C’est le format temporel le plus utilisé en informatique — chaque base de données, ligne de log, JWT et cookie HTTP s’appuie finalement dessus. Il est aussi plein de pièges qui ne s’annoncent pas avant que vos données soient déjà erronées.

Ce que c’est, précisément

Un timestamp Unix est le nombre de secondes (ou de millisecondes, microsecondes, nanosecondes — choisissez une unité) écoulées depuis le 1970-01-01T00:00:00 UTC, communément appelé “l’époque Unix.” Aujourd’hui, c’est un nombre dans les 1,7 milliards pour les secondes, ou 1,7 trillion pour les millisecondes.

Vous pouvez convertir un timestamp en date calendaire et inversement avec notre convertisseur de timestamp— collez n’importe quel entier et voyez la date UTC, votre date locale et le temps relatif.

Pourquoi 1970 ?

Le choix n’est pas profond. Bell Labs a livré Unix v1 en 1971 et avait besoin d’une date récente arbitraire pour le compteur de temps. Un prototype antérieur comptait des ticks au 1/60 de seconde depuis le 1er janvier 1971, mais le compteur 32 bits aurait débordé en moins de 2,5 ans. L’équipe est passée aux secondes entières et a antidaté l’époque au 1er janvier 1970 afin que les dates antérieures puissent être représentées en négatif. Cela a persisté parce que chaque système en aval l’a verrouillé.

Précision : secondes, ms, μs, ns

Différentes couches de la pile utilisent différentes unités :

• Secondes — Unix classique time(), claims JWT iat/exp, en-têtes HTTP Date, la plupart des exports tableurs.
• Millisecondes — JavaScript Date.now(), Java System.currentTimeMillis(), timestamps Kafka, MongoDB ObjectId (les 4 premiers octets sont des secondes-depuis-époque, compressées avec d’autres champs en BSON).
• Microsecondes — Postgres TIMESTAMP, MySQL DATETIME(6), bibliothèques de traçage (Jaeger, OpenTelemetry).
• Nanosecondes — Linux clock_gettime(CLOCK_REALTIME), Go time.Now().UnixNano(), etcd, exporteurs OpenTelemetry récents.

À une frontière d’API, ne supposez jamais. 1700000000 est novembre 2023 lu en secondes, janvier 1970 plus 20 jours lu en millisecondes. Heuristique rapide : si l’entier fait environ 10 chiffres, c’est des secondes ; 13 chiffres, des millisecondes ; 16, des microsecondes ; 19, des nanosecondes. Notre outil timestamp détecte automatiquement les quatre.

Secondes intercalaires : le mensonge en bas

POSIX définit un timestamp Unix comme des “secondes depuis l’époque” tout en supposant explicitement que chaque jour compte 86 400 secondes. L’UTC réel non. Depuis 1972, 27 secondes intercalaires positives ont été insérées pour maintenir l’UTC aligné avec la rotation de la Terre. La plus récente était le 30 juin 2017.

Le comportement strict POSIX est de geler l’horloge pendant une seconde intercalaire : le timestamp 1483228827est servi deux secondes de suite. Cela brise la monotonicité et fait planter tout ce qui suppose que les timestamps sont uniques. L’alternative de Google, le “leap smearing”, répartit la seconde supplémentaire sur une fenêtre de 24 heures afin qu’aucune seconde individuelle ne soit répétée ; AWS, Meta et Microsoft font désormais de même. Deux serveurs utilisant des schémas différents peuvent diverger d’une demi-seconde autour d’un événement de saut.

Pour 99 % des applications, cela n’a pas d’importance. Pour tout ce qui ordonne des événements avec une précision inférieure à la seconde entre plusieurs fournisseurs, c’est absolument important.

Le problème de l’an 2038

Un entier signé de 32 bits peut contenir des valeurs de −2 147 483 648 à +2 147 483 647. Interprété comme des secondes depuis le 1er janvier 1970 UTC, la borne supérieure est 2038-01-19T03:14:07Z. Une seconde plus tard, le compteur boucle vers la valeur la plus négative, représentant le 13 décembre 1901.

Les systèmes d’exploitation 64 bits modernes utilisent déjà un time_t64 bits, qui ne déborde pas avant 292 milliards d’années. L’exposition restante :

• Appareils embarqués — calculateurs automobiles, automates industriels, implants médicaux. Beaucoup utilisent encore le temps 32 bits et ne sont pas mis à jour.
• Formats de fichiers— horodatages d’inodes ext2/ext3, ZIP classique (format DOS), anciens attributs étendus NTFS.
• Colonnes SQL — une colonne déclarée INTpour “économiser de l’espace” pour les epoch seconds. Auditez vos schémas maintenant, pas en 2037.
• Code C legacy compilé contre une ancienne libc sur ARM 32 bits. La migration vers time_t64 bits est une rupture ABI et de nombreux fournisseurs ne l’ont pas encore publiée.

Pour un traitement plus approfondi, consultez notre entrée de glossaire Unix timestamp.

Temps Unix vs ISO 8601

ISO 8601 (et son profil Internet, RFC 3339) écrit le temps sous la forme 2026-05-31T14:30:00Z. C’est lisible par l’homme, conscient du fuseau horaire et auto-descriptif. Le temps Unix est compact, triable comme entier et sans ambiguïté sur l’instant réel — mais ne dit rien sur quel fuseau l’auteur entendait afficher.

Utilisez ISO 8601 dans les API, les logs et partout où un humain lira la valeur. Utilisez les entiers Unix en stockage quand l’espace et les calculs importent, ou quand le tri doit être rapide. De nombreux systèmes portent les deux — l’entier pour les opérations, la chaîne pour les pistes d’audit. Consultez l’ entrée de glossaire ISO 8601 pour la grammaire complète.

Pièges courants

Analyse sans conscience du fuseau horaire

new Date("2026-05-31") en JavaScript est analysé comme UTC minuit, mais new Date("2026-05-31 14:00") (notez l’espace, pas un T) est analysé comme heure locale sur la plupart des moteurs. Les timestamps Unix résultants diffèrent de votre décalage. Incluez toujours le désignateur de fuseau horaire (Z, +09:00) sur les entrées que vous ne contrôlez pas entièrement.

Mélange silencieux des unités

Un microservice qui émet des millisecondes parle à un aval qui attend des secondes. L’aval voit des timestamps en l’an 55000 et les écrit silencieusement dans la base de données. Validez toujours la magnitude des timestamps entrants par rapport à une plage plausible.

Epochs en heure locale

Certains systèmes legacy calculent des “secondes depuis le 1er janvier 1970 heure locale.” Ce n’est pas du temps Unix et ça casse dès qu’un serveur est déplacé ou que l’heure d’été change. Si vous héritez d’un tel système, enregistrez le décalage avec l’entier et convertissez en véritable epoch UTC à la frontière.

Essayez le convertisseur

Collez n’importe quel entier dans notre convertisseur de timestamppour voir les interprétations UTC et locale côte à côte, avec détection automatique des secondes/ms/μs/ns. Pour la conversion par lots ou des contrôles de précision supplémentaires, l’ outil timestamp datetime gère les deux directions.

Conclusion

Le temps Unix est un excellent défaut car il est compact, triable et sans ambiguïté sur l’instant. C’est un mauvais défaut dès que vous oubliez dans quelle unité vous êtes, quel fuseau vous voulez afficher, ou si votre stockage est 32 bits. L’époque était un choix pragmatique en 1970 ; la falaise de 2038 est la facture à payer. Auditez vos colonnes entières, documentez vos unités et ne stockez pas d’epochs en heure locale.