Convertisseur de timestamp Unix

Qu’est-ce qu’un timestamp Unix

Un timestamp Unix (epoch / temps POSIX) compte les secondes écoulées depuis le 1er janvier 1970 à 00:00:00 UTC, sans tenir compte des secondes intercalaires. Comme il s’agit d’un nombre unique exprimé en UTC, il désigne un instant exact indépendamment du fuseau horaire — c’est pour cela que les bases de données, les journaux et les API l’utilisent. Par exemple, 1700000000 correspond à Tue, 14 Nov 2023 22:13:20 GMT (ISO 8601 : 2023-11-14T22:13:20.000Z).

Secondes ou millisecondes

Le temps Unix classique est exprimé en secondes (une valeur actuelle compte 10 chiffres). JavaScript et de nombreuses plateformes utilisent les millisecondes (13 chiffres). Si vous collez une valeur de 13 chiffres avec l’unité réglée sur « Détection automatique », cet outil la traite comme des millisecondes. Intervalles courants en secondes :

Le problème de l’an 2038

Un logiciel qui stocke le timestamp dans un entier signé de 32 bits ne peut compter que jusqu’à 2 147 483 647 secondes — valeur atteinte le 19 janvier 2038 à 03:14:07 UTC. Au-delà, la valeur déborde et devient un nombre négatif. La solution consiste à stocker le temps dans des entiers de 64 bits, ce que font tous les systèmes modernes.

D’où vient l’epoch de 1970

Le point de départ familier de 1970 n’était pas le premier. La toute première édition du manuel du programmeur Unix, rédigée aux Bell Labs en novembre 1971, définissait l’heure système comme le nombre de soixantièmes de seconde écoulés depuis le 1er janvier 1971 à 00:00:00. Compter en tops de 1/60 de seconde correspondait à la fréquence secteur de 60 Hz qui cadençait l’horloge des premiers PDP-11, mais un compteur de 32 bits qui avance 60 fois par seconde épuise sa capacité en 2,26 ans environ — un manuel ultérieur notait sans détour que cela « garantit une crise tous les 2,26 ans ».

La correction, fixée par les manuels de 1972–1973, a été double : compter des secondes entières au lieu des tops, et déplacer le point zéro vers la date ronde du 1er janvier 1970 UTC. Passer des soixantièmes aux secondes a multiplié d’un coup la plage utilisable par soixante, et les ingénieurs — Ken Thompson, Dennis Ritchie et leurs collègues — ont choisi 1970 simplement parce que c’était un nombre pratique et rond pour travailler. Ce choix arbitraire et pragmatique est depuis devenu l’une des constantes les plus discrètement essentielles de l’informatique : chaque système d’exploitation, base de données et langage de programmation moderne compte encore à partir de cet instant précis.

Les secondes intercalaires, et pourquoi chaque jour Unix dure exactement 86 400 secondes

La norme POSIX définit le temps Unix de sorte que chaque jour contienne exactement 86 400 secondes (60 × 60 × 24). Cela paraît évident jusqu’à ce que l’on se souvienne que l’heure civile est l’UTC, et que l’UTC insère parfois une seconde intercalaire pour garder les horloges alignées sur la rotation légèrement irrégulière de la Terre. Un jour comportant une seconde intercalaire positive, l’UTC dure réellement 86 401 secondes — mais le temps Unix a l’interdiction formelle de l’admettre : il ne compte tout simplement pas la seconde supplémentaire.

Il en résulte une ambiguïté faible mais bien réelle. La valeur limite 1483228800, par exemple, peut désigner soit la seconde intercalaire 2016-12-31 23:59:60 UTC, soit la seconde ordinaire suivante, 2017-01-01 00:00:00 UTC — deux instants réels différents qui partagent un même timestamp, car la même valeur Unix sert pendant deux secondes consécutives afin que le minuit suivant tombe encore sur un multiple exact de 86 400. Conséquence pratique : un timestamp Unix stocké ne peut pas représenter sans ambiguïté une seconde intercalaire, et l’écart entre deux timestamps situés de part et d’autre de l’une d’elles est faussé du nombre de secondes intercalaires intermédiaires. Pour la plupart des logiciels, c’est invisible ; les systèmes de haute précision utilisent le TAI ou « lissent » (smear) la seconde intercalaire progressivement sur une journée.

Timestamps négatifs : désigner un instant avant l’epoch

Comme time_t est un entier signé, les timestamps ne sont pas limités aux dates postérieures à 1970 — ils peuvent devenir négatifs pour désigner le passé, en diminuant d’une unité pour chaque seconde avant l’epoch. Minuit le 1er janvier 1969 UTC correspond à -31536000 (exactement une année non bissextile plus tôt), et la valeur la plus négative que peut contenir un champ signé de 32 bits, -2147483648, tombe le 13 décembre 1901 à 20:45:52 UTC — le reflet exact de la limite de 2038. Les epochs négatifs sont normaux pour stocker des dates historiques, mais ils sont une source fréquente de bogues : une bibliothèque ou une colonne de base de données qui suppose des timestamps non signés traitera mal tout ce qui précède 1970, et certains anciens systèmes refusent purement et simplement les valeurs négatives.

Précision inférieure à la seconde : millisecondes, microsecondes, nanosecondes

Le temps Unix brut a une résolution d’une seconde, mais la plupart des plateformes l’étendent, et le nombre de chiffres est l’indice le plus rapide : une valeur actuelle compte 10 chiffres en secondes, 13 en millisecondes, 16 en microsecondes et 19 en nanosecondes. JavaScript travaille nativement en millisecondes — Date.now() renvoie une valeur de 13 chiffres — donc revenir aux secondes classiques implique de diviser par 1 000. En Python, time.time() renvoie un nombre flottant de secondes avec une précision de l’ordre de la microseconde, tandis que time.time_ns() renvoie un nombre entier de nanosecondes. En Go, time.Now().UnixNano(), ainsi que de nombreuses bases de données, descendent également jusqu’à la nanoseconde. Mélanger ces unités est le bogue d’epoch le plus courant — voir les pièges ci-dessous.

Lire l’epoch actuel dans n’importe quel environnement

Presque tous les langages et shells exposent directement le temps Unix actuel. Le tableau ci-dessous donne l’appel idiomatique dans plusieurs environnements courants (chacun renvoie des secondes entières, sauf mention contraire) :

Unix n’est pas le seul point zéro

Chaque système a été conçu autour de sa propre epoch : « des secondes depuis une epoch » ne veut donc rien dire tant que l’on ne sait pas laquelle, et les timestamps ne sont pas transposables d’une plateforme à l’autre sans conversion. Les points de référence les plus importants :

La bizarrerie d’Excel est le piège classique : pour rester compatible, bogue compris, avec Lotus 1-2-3, Excel considère que la date inexistante du 29 février 1900 a bien existé ; son compteur de jours est donc décalé d’une unité pour toute date du début de 1900, et son epoch effective est fixée au 30 décembre 1899 pour compenser. Windows utilise 1601 parce que cette année ouvre le cycle de 400 ans du calendrier grégorien, ce qui simplifie le calcul des années bissextiles.

Timestamps symboliques et l’horizon des 292 milliards d’années

Comme le temps Unix n’est qu’un compteur, certaines valeurs rondes ou curieuses sont devenues de petites fêtes pour les geeks :

Au-delà de 2038, la réponse à long terme est déjà déployée : stocker le compteur dans un entier signé de 64 bits repousse le débordement à environ 292 milliards d’années de part et d’autre de 1970 — bien au-delà de la durée de vie prévue du Soleil. Linux moderne, la bibliothèque C et la plupart des langages sont passés à un time_t sur 64 bits depuis des années ; le risque résiduel de 2038 se trouve dans les anciens binaires 32 bits, les micrologiciels embarqués et les vieux formats de fichiers ou de protocoles réseau qui stockent encore le timestamp sur 32 bits.

Pièges courants avec les epochs

• Secondes ou millisecondes. Une valeur de 10 chiffres est en secondes ; 13 chiffres, ce sont des millisecondes. Fournir des secondes à une API qui attend des millisecondes ramène la date en 1970, et l’inverse la projette des dizaines de milliers d’années dans le futur.
• Le ×1000 oublié (ou en trop). En JavaScript, new Date(n) attend des millisecondes : passer une valeur en secondes exige n * 1000 — l’oublier est le bogue d’epoch le plus répandu.
• Prendre l’epoch pour une heure locale. Un timestamp Unix est toujours en UTC. L’afficher sans préciser de fuseau horaire décale silencieusement l’heure affichée du décalage de votre machine.
• Arrondi décalé d’une unité. Pour convertir des millisecondes en secondes, il faut généralement tronquer (arrondi inférieur), pas arrondir au plus proche, sinon un événement peut sembler s’être produit une seconde plus tard qu’en réalité.
• Supposer des valeurs non signées. Les dates antérieures à 1970 sont négatives ; un code ou des colonnes qui supposent des timestamps positifs abîmeront les données historiques.

Heure murale et horloge monotone

Un piège qui surprend même les développeurs expérimentés : un timestamp Unix est une heure murale (wall-clock), et l’heure murale peut faire des sauts. Les corrections NTP la font avancer ou reculer, un administrateur peut la réinitialiser, les mises à jour de la base des fuseaux horaires modifient l’affichage local, et le lissage des secondes intercalaires la ralentit ou l’accélère volontairement pendant une journée. Par conséquent, soustraire deux timestamps Unix pour mesurer la durée d’une opération peut donner une durée négative ou complètement fausse si l’horloge a été ajustée entre-temps. Pour mesurer un temps écoulé, lisez plutôt une horloge monotone — qui ne fait qu’avancer et n’est pas affectée par les ajustements de l’heure murale — comme performance.now() dans le navigateur, time.monotonic() en Python ou CLOCK_MONOTONIC sous Linux. Utilisez l’epoch Unix pour enregistrer quand un événement a eu lieu ; utilisez une horloge monotone pour mesurer combien de temps il a duré.

Pourquoi stocker l’epoch plutôt qu’une date formatée

Lorsque vous maîtrisez le format de stockage, un entier Unix brut est presque toujours un meilleur choix qu’une chaîne lisible. Il est compact, se trie correctement comme un simple nombre, se compare et se calcule facilement, et — surtout — ne comporte aucune ambiguïté de fuseau horaire, puisqu’il est toujours en UTC. Une chaîne comme « 01/02/03 » est en comparaison inutilisable : elle peut désigner trois dates différentes selon la langue et la région, et on ne peut pas la soustraire. Le format d’échange standard, lorsque vous avez vraiment besoin de texte, est ISO 8601 / RFC 3339 (par exemple 2009-02-13T23:31:30Z), dont le « Z » final l’ancre en UTC et dont l’ordre lexical correspond à l’ordre chronologique. La règle d’or : stockez et transmettez l’epoch (ou une chaîne ISO 8601 explicitement en UTC), et ne la mettez en forme en texte local et lisible qu’au tout dernier moment, dans l’interface utilisateur.

Questions fréquentes

Qu’est-ce qu’un timestamp Unix ?

Un timestamp Unix (aussi appelé epoch ou temps POSIX) est le nombre de secondes écoulées depuis le 1er janvier 1970 à 00:00:00 UTC (l’« epoch Unix »), sans compter les secondes intercalaires. C’est une façon de stocker un instant indépendamment de tout fuseau horaire.

Le timestamp est-il en secondes ou en millisecondes ?

Les timestamps Unix sont traditionnellement exprimés en secondes (10 chiffres pour les dates actuelles). JavaScript, Java et de nombreuses API utilisent les millisecondes (13 chiffres). Cet outil vous permet de choisir l’unité et détecte automatiquement une saisie de 13 chiffres comme des millisecondes.

Qu’est-ce que le problème de l’an 2038 ?

Les systèmes qui stockent le timestamp dans un entier signé de 32 bits débordent le 19 janvier 2038 à 03:14:07 UTC, lorsque la valeur dépasse 2 147 483 647. Les systèmes modernes en 64 bits ne sont pas concernés ; la solution consiste à stocker le temps dans des entiers de 64 bits.

La conversion a-t-elle lieu sur vos serveurs ?

Non. Tout s’exécute dans votre navigateur avec l’API Date native : vos valeurs ne sont jamais envoyées. L’outil fonctionne aussi hors ligne une fois la page chargée.

Outils associés

• Convertisseur d’unités de temps
• Minutes dans un mois
• Générateur d’UUID
• Formateur et validateur JSON
• Encodeur / décodeur Base64

Voir toutes les conversions pour développeurs et données →