Convertisseur de Timestamp

Convertis un timestamp Unix en UTC, heure locale et ISO 8601, avec vues lot et timezone.

Ce convertisseur de timestamp transforme n'importe quel timestamp Unix en UTC, ton heure locale, l'ISO 8601, le RFC 2822 et le SQL, puis aligne le même instant sur une poignée de timezones. Colle un nombre à 10 chiffres, un à 13 chiffres ou une date lisible et il détecte tout seul s'il s'agit de seconds, milliseconds, micro ou nano, pour t'éviter de lire l'un comme l'autre. Il est pensé pour les moments de bazar : debug de logs, claims JWT exp et iat, schedulers, sauvegardes et la ligne de base de données un peu bizarre. Balance un lot de lignes de log mélangées et il ressort un CSV propre à coller direct dans un ticket. Le temps Unix repose sur UTC, donc choisir une timezone change juste la façon dont le moment se lit, jamais le moment lui même. Tout tourne dans ton navigateur, donc rien de ce que tu colles ne quitte la page.

100% dans votre navigateur. Rien de ce que vous tapez ne quitte cette page.

Convertisseur de timestamp Unix, date ISO, timezone et lot

Colle un nombre Unix (seconds, milliseconds, micro, ce que tu veux) ou une date lisible, et tu récupères l'UTC, ton heure locale, l'ISO 8601, le RFC 2822, le SQL, plus le même instant dans quelques timezones. L'outil avale aussi un lot de lignes de log et décortique les date claims d'un JWT. En vrai, il existe surtout pour t'éviter de lire un nombre à 10 chiffres comme des seconds alors que c'était des milliseconds depuis le début. Ça m'est arrivé.

Timestamp ou date

Mode d'entrée

Timezone de focus

Timestamps en lot, un par ligne

Tout tourne dans ton navigateur. Et n'oublie pas : le temps Unix repose sur l'UTC. Choisir une timezone change juste la façon dont on le lit, pas le moment réel.

Convertir un timestamp, c'est surtout deviner la bonne unité

Un convertisseur de timestamp Unix t'évite la seule erreur que tout le monde fait : lire le nombre dans la mauvaise unité. Les Unix timestamps ont l'air inoffensifs parce que ce sont juste des nombres, et c'est exactement pour ça qu'ils mordent. Certains systèmes te donnent des seconds, JavaScript renvoie des milliseconds, une base de données peut très bien stocker des microseconds, et un pipeline d'événements quelque part logge des nanoseconds parce que pourquoi pas. Une valeur à 10 chiffres et une à 13 chiffres peuvent désigner le même instant, si l'une est en seconds et l'autre en milliseconds. Lis la dans la mauvaise unité et ta date saute de plusieurs décennies. Cet outil repère tout seul les longueurs de chiffres habituelles, mais tu peux aussi forcer seconds, milliseconds, micro ou nano quand tu sais déjà.

Comment lire des timestamps sans se planter

Commence par identifier l'unité. Pour des dates récentes, les Unix seconds font en général 10 chiffres et les milliseconds 13. Micro et nano sont plus longs, et c'est franchement plus de précision qu'une date JavaScript classique n'en demande, donc la date affichée ici s'appuie sur la partie milliseconde. Ensuite, garde le stockage et l'affichage dans deux cases séparées. Stocke des instants UTC. Formate les pour l'humain tout au bout, là où tu les affiches. Et dès qu'il y a une vraie échéance ou le calendrier de quelqu'un en jeu, dis la timezone à voix haute.

Unix seconds apparaissent dans les claims JWT exp, nbf et iat.
Unix milliseconds sont le défaut de JavaScript, donc tu les verras dans les logs de navigateur et pas mal d'APIs.
ISO 8601 est en général le format le moins pénible à se passer entre systèmes.
Les vues par timezone te disent ce qu'un même instant veut vraiment dire à Paris, en UTC ou à Tokyo.
La conversion en lot gagne son pain en plein incident, quand les logs sont une soupe de formats mélangés.

Exemples courants de debug de timestamps

Un token qui meurt à la seconde où il est émis ? Décode le JWT et passe le claim exp en Unix seconds, tu lui as sans doute filé des milliseconds. Un cron qui se déclenche à une heure bizarre ? Aligne la timezone du serveur sur celle de l'humain avant de toucher quoi que ce soit. Une date de log coincée en 1970 ou perdue loin dans le futur, ça veut presque toujours dire que seconds et milliseconds se sont échangés quelque part. Et quand deux régions n'arrivent pas à s'accorder sur une date, ne te lance pas à réécrire la logique applicative tout de suite. Compare d'abord exactement le même instant UTC dans les deux zones. Neuf fois sur dix la donnée était bonne et c'est l'affichage qui mentait.

Questions fréquentes

Le temps Unix est-il affecté par la timezone ?

Non. Il compte depuis l'epoch UTC, point. Les timezones changent seulement la façon dont cet instant est habillé pour qu'un humain le lise. Le nombre en dessous, lui, ne bouge pas.

Pourquoi les timestamps JavaScript ont ils 13 chiffres ?

Parce que Date en JavaScript compte les milliseconds depuis l'epoch, pas les seconds. Pas mal d'APIs utilisent les seconds cela dit, et c'est précisément ce décalage qui fait se glisser les bugs de facteur 1000.

Comment convertir un timestamp Unix en date ?

Pose le nombre epoch dans la case tout en haut. Il devine l'unité (seconds, milliseconds, micro, nano) et te ressort ton heure locale à côté de l'UTC et d'une jolie ISO 8601 string. Si la devinette a l'air à côté, force l'unité avec le menu déroulant et reconvertis.

C'est quoi le problème de l'an 2038 ?

Tout ce qui entasse encore du temps Unix dans un entier 32 bit signé arrive à court de place le 19 janvier 2038 et se retrouve à boucler vers une date négative, qui ressemble à 1901. Le correctif est barbant et déjà appliqué presque partout : utiliser une valeur 64 bit. Les langages et bases de données modernes prennent ça par défaut désormais. Les retardataires, ce sont surtout les vieux équipements embarqués que personne n'a envie de toucher.