schedule Convertisseur de Timestamp Unix star

Comment ça fonctionne

Un timestamp Unix compte les secondes entières écoulées depuis 00:00:00 UTC le 1er janvier 1970 — un point de référence fixe appelé l'epoch. Le nombre 1 784 000 000 se situe en juillet 2026 ; chaque seconde depuis 1970 possède son propre entier unique, sans aucune notion de fuseau horaire, de mois calendaire ou d'heure d'été intégrée. C'est exactement pour cela que les bases de données, les API et les fichiers journaux stockent le temps de cette manière : deux serveurs aux extrémités opposées de la planète calculent le même timestamp pour le même instant, et trier des timestamps numériquement équivaut à les trier chronologiquement — sans aucune logique d'analyse de date nécessaire.

Convertir un timestamp en date lisible signifie interpréter cet entier par rapport à un fuseau horaire précis : l'instant sous-jacent ne change pas, seule sa représentation change. Cet outil affiche côte à côte votre fuseau horaire local et l'UTC afin qu'un décalage soit facile à repérer — par exemple, le timestamp 1784000000 se lit 2026-07-13 22:13:20 UTC, ce qui devient 2026-07-14 01:13:20 en UTC+3. Dans l'autre sens — date lisible vers timestamp — la même logique s'applique à l'envers : l'outil prend les champs de date que vous saisissez, les traite comme appartenant au fuseau horaire que vous avez sélectionné, et calcule l'entier epoch équivalent. Les secondes et les millisecondes sont détectées automatiquement selon le nombre de chiffres, donc coller l'un ou l'autre format fonctionne sans configuration.

Ce que vous devez savoir

Un entier signé classique sur 32 bits ne peut compter que jusqu'à 2 147 483 647 secondes après l'epoch, atteint à 03:14:07 UTC le 19 janvier 2038 — le fameux « problème de l'an 2038 ». Les systèmes qui stockent encore les timestamps sur 32 bits basculeront vers un nombre négatif à cet instant précis, un peu dans l'esprit du bug de l'an 2000. Les systèmes modernes 64 bits stockent la même valeur dans un entier bien plus grand et restent valides pendant environ 292 milliards d'années, si bien que les bases de données, systèmes d'exploitation et langages contemporains ne sont pas concernés. Les timestamps négatifs sont également valides — ils encodent simplement des dates antérieures au 1er janvier 1970, en comptant à rebours. Une autre subtilité à connaître : une seconde intercalaire est parfois insérée dans l'UTC pour rester alignée sur la rotation de la Terre, mais la norme du timestamp Unix ignore entièrement les secondes intercalaires, traitant chaque jour comme exactement 86 400 secondes — ce qui garde l'arithmétique des timestamps simple, au prix d'une exactitude astronomique imparfaite.

Les timestamps Unix apparaissent constamment dans le développement quotidien : les JSON Web Tokens encodent leur expiration dans une revendication exp en secondes epoch, les en-têtes de cache HTTP et les cookies fixent souvent leur expiration de la même façon, et les systèmes de planification comparent l'epoch actuel à une valeur cible pour décider quand se déclencher. Comme le format n'est qu'un entier, l'arithmétique de dates dessus est triviale : ajouter 86 400 à un timestamp signifie toujours exactement un jour plus tard en UTC, quel que soit le mois ou l'année bissextile concernée — ce que l'arithmétique sur des dates calendaires rend bien plus sujette aux erreurs. C'est aussi pourquoi presque tous les langages de programmation exposent une fonction simple pour lire « maintenant » comme un timestamp — time() en PHP, Date.now() en JavaScript, time.time() en Python — et pourquoi comparer deux timestamps comme de simples nombres suffit à savoir quel événement s'est produit en premier, peu importe où dans le monde chacun a eu lieu.