Convertisseur de timestamp Unix

Comment convertir un timestamp Unix

1. Collez un timestamp dans le champ, en secondes ou en millisecondes.
2. Lisez la date et l'heure converties, affichées à la fois en UTC et dans votre fuseau local.
3. Pour le sens inverse, saisissez une date et une heure dans les champs de date.
4. Copiez la valeur epoch obtenue pour votre requête, votre script ou votre appel d'API.
5. Consultez le timestamp actuel en direct en haut de page quand il vous faut juste « maintenant ».

Ce que fait ce convertisseur

L'outil traduit dans les deux sens entre temps epoch et dates lisibles. Collez un timestamp Unix pour voir l'instant exact qu'il représente, affiché à la fois en UTC et dans votre fuseau horaire local, ou choisissez une date et une heure pour récupérer la valeur epoch. Un timestamp actuel en direct défile en haut chaque fois qu'il vous faut simplement « maintenant ».

Tout se passe localement dans votre navigateur, instantanément et en privé. Secondes et millisecondes sont gérées, et le résultat est toujours le même moment sous-jacent, simplement affiché dans le fuseau que vous êtes en train de lire.

Secondes vs millisecondes : le classique facteur 1000

Si une date convertie atterrit dans les années 1970, votre timestamp est en secondes mais a été interprété en millisecondes, ou l'inverse si la date se retrouve des dizaines de milliers d'années dans le futur. Règle pratique : les timestamps actuels en secondes ont 10 chiffres, en millisecondes 13. L'outil détecte la longueur et convertit en conséquence, mais il vaut la peine de savoir d'où vient la confusion : les outils Unix et la plupart des API utilisent des secondes, tandis que JavaScript et Java utilisent des millisecondes.

Rappelez-vous aussi qu'un timestamp n'a pas de fuseau horaire. C'est un instant global unique ; les fuseaux n'apparaissent qu'au moment de le formater en date. C'est pourquoi le même epoch s'affiche comme des heures différentes en UTC et dans votre fuseau local.

Ce qu'est réellement le temps Unix

Le temps Unix est le décompte des secondes écoulées depuis le 1er janvier 1970 à 00:00:00 UTC, un moment appelé l'epoch. Il donne à chaque instant un unique nombre sans ambiguïté, sans nom de mois, sans séparateur et sans locale à gérer, ce qui explique pourquoi les systèmes le stockent en interne plutôt que des chaînes de date formatées.

Élément crucial : ce nombre est un instant UTC absolu. Il ne porte pas de fuseau horaire propre ; un fuseau n'est appliqué qu'au moment où vous le rendez sous forme de date lisible. Le même timestamp est le même moment pour tout le monde sur Terre, même si l'horloge murale affiche une heure différente à Londres, New York et Tokyo.

Où l'on croise les timestamps

Les valeurs epoch sont partout dans le logiciel : fichiers de logs, claims d'expiration et d'émission des JWT, payloads de requêtes et de réponses d'API, lignes de bases de données, en-têtes de cache et débogage de crons. Quand un log dit qu'un événement s'est produit à 1757203200, le convertir vous dit si c'était avant ou après un déploiement, ce qui est généralement toute la question.

C'est aussi la façon la plus sûre de faire passer un moment d'un système à l'autre. Comme un timestamp est sans fuseau, un serveur, un client et une base de données peuvent chacun stocker le même nombre et l'afficher dans le fuseau que préfère leur utilisateur, sans aucune ambiguïté sur l'instant visé.

Fuseaux horaires et formatage

Ce convertisseur affiche chaque timestamp à la fois en UTC et dans le fuseau local de votre navigateur, pour que vous voyiez immédiatement le décalage. Si une date paraît « décalée » de plusieurs heures, vous comparez presque toujours l'UTC à l'heure locale plutôt que de voir un bug ; l'instant est identique, seule la présentation diffère.

Une bonne habitude est de savoir quel fuseau utilise votre source. Les serveurs journalisent massivement en UTC : alignez donc votre lecture là-dessus quand vous corrélez des événements, et ne passez à l'heure locale que lorsque vous raisonnez sur ce qu'un utilisateur précis a vécu à son emplacement.

Le bug de l'an 2038 et les limites du 32 bits

Les systèmes qui stockent le temps Unix dans un entier signé 32 bits ne peuvent compter que jusqu'à 2 147 483 647 secondes, atteint le 19 janvier 2038 à 03:14:07 UTC. Passé ce point, la valeur déborde et bascule vers un nombre négatif, retombant en 1901, l'équivalent, à l'échelle de l'epoch, du bug de l'an 2000.

Les systèmes 64 bits modernes repoussent ce plafond à des milliards d'années dans le futur, et ce convertisseur gère lui-même des dates bien au-delà de 2038 ainsi que des timestamps négatifs antérieurs à 1970. La leçon pratique est de s'assurer que tout code qui stocke ou transmet du temps epoch utilise un type 64 bits.

Erreurs courantes et outils associés

Les erreurs récurrentes sont la confusion secondes/millisecondes, l'oubli qu'un timestamp brut n'a pas de fuseau horaire, et le fait de tronquer au lieu d'arrondir lors du passage d'une unité à l'autre. Garder en tête la règle du nombre de chiffres, 10 pour les secondes et 13 pour les millisecondes aux dates actuelles, permet d'en repérer la plupart d'un coup d'œil.

Pour les tâches connexes, cet outil accompagne les autres utilitaires pour développeurs du site, qui s'exécutent tous entièrement côté client. Que vous décodiez le claim exp d'un payload de JWT ou que vous aligniez des entrées de log sur une version, la conversion ici est exacte et reste sur votre machine.

Questions fréquentes

Outils associés