Convertisseur de timestamp Unix, gratuit

Ce qu'est vraiment le temps Unix epoch

Le temps Unix epoch (aussi appelé temps POSIX, temps Unix, ou simplement « epoch ») est un système de représentation des instants dans le temps sous la forme d'un seul entier : le nombre de secondes (ou de millisecondes, en JavaScript et beaucoup de systèmes modernes) écoulées depuis l'epoch Unix, fixée à 00 h 00 min 00 s UTC le 1ᵉʳ janvier 1970. Les nombres négatifs représentent les instants antérieurs à l'epoch ; les positifs, postérieurs. La représentation par un seul entier a des propriétés convaincantes : elle est indépendante du fuseau horaire (le nombre est le même partout sur Terre au même instant), elle est facile à comparer (les instants postérieurs sont des nombres plus grands), et le calcul de durées est trivial (soustraction). Le temps Unix est la représentation sous-jacente du temps dans pratiquement chaque système d'exploitation, chaque moteur de base de données, chaque protocole d'API et chaque bibliothèque standard de langage de programmation, même les systèmes dont l'interface utilisateur affiche des dates calendaires stockent les valeurs sous-jacentes sous forme d'entiers epoch.

Le choix du 1ᵉʳ janvier 1970, et autres epochs

L'epoch 1970-01-01 remonte aux débuts d'Unix aux Bell Labs. Le type time_t d'Unix était à l'origine un entier signé sur 32 bits comptant les secondes depuis une référence choisie ; l'équipe a retenu le Nouvel An le plus récent avant le début du développement, soit le 1ᵉʳ janvier 1970. La décision était pratique, pas philosophique, Unix était en cours de développement entre 1969 et 1971, et une epoch récente maximisait la plage utilisable des timestamps dans la plage signée 32 bits. D'autres systèmes ont choisi d'autres epochs adaptées à leurs cas d'usage. NTP (Network Time Protocol, RFC 5905) utilise le 1ᵉʳ janvier 1900, important parce que NTP devait couvrir des plages historiques plus longues. Windows FILETIME utilise le 1ᵉʳ janvier 1601 comme epoch en ticks de 100 nanosecondes (le début du cycle grégorien de 400 ans qui incluait 1601). VAX/VMS a utilisé le 17 novembre 1858 (l'epoch du jour julien modifié, populaire en astronomie). Mac classic a utilisé le 1ᵉʳ janvier 1904. JavaScript Date utilise l'epoch Unix mais compte des millisecondes plutôt que des secondes (un flottant 64 bits, donnant ±100 millions d'années de plage utilisable). Le constat : l'epoch Unix domine en 2026, mais l'historique contient bien d'autres choix, chacun avec son propre legacy de rétrocompatibilité.

Le problème Y2K38, le temps Unix va expirer (en quelque sorte)

Si time_t est un entier signé sur 32 bits (le design Unix original), le timestamp maximum représentable est 2 147 483 647, ce qui correspond au mardi 19 janvier 2038 à 03 h 14 min 07 s UTC. Une seconde plus tard, la valeur déborde en négatif et boucle vers le 13 décembre 1901. C'est le problème Y2K38 (aussi appelé Epochalypse). Sur les systèmes 64 bits modernes, time_t est un entier signé sur 64 bits et la date de débordement est le 4 décembre 292 277 026 596, bien après la mort du Soleil. Mais les systèmes embarqués 32 bits sont encore activement déployés dans des automates industriels, des satellites à longue mission, des back-ends bancaires, des réseaux SCADA pétroliers et gaziers, l'infodivertissement automobile et des capteurs IoT avec des durées de vie de plusieurs décennies. La mitigation est en cours depuis le début des années 2000, chaque grand OS, base de données et langage utilise désormais par défaut un temps 64 bits sur matériel 64 bits (Linux a achevé la transition au noyau 5.6 en mars 2020 ; Windows a toujours utilisé du 64 bits ; macOS Catalina a abandonné le support 32 bits en 2019). Les systèmes embarqués sont la longue traîne. Le problème Y2K38 ne sera pas une crise d'un seul jour comme Y2K l'a été ; ce sera une série de petites pannes dans les systèmes en longue traîne au fil des années approchant 2038, exactement comme Y2K s'est manifesté principalement dans des systèmes obscurs que personne n'avait patchés.

ISO 8601, l'autre format de temps standard

Là où le temps Unix est le format de transport, ISO 8601 est le format lisible. Publié à l'origine sous ISO 8601:1988, révisé en 2000, 2004 et plus récemment en ISO 8601-1:2019 et ISO 8601-2:2019, le standard définit des représentations comme 2026-05-03T14:30:00Z (où Z signifie UTC) ou 2026-05-03T14:30:00+01:00 (avec décalage explicite). Le « T » sépare la date de l'heure ; le décalage de fin lève l'ambiguïté du fuseau horaire. Pour les protocoles internet, RFC 3339 (Klyne et Newman, 2002) définit un sous-ensemble strict d'ISO 8601 plus simple à parser, c'est le format que l'on rencontre dans les réponses JSON d'API, les timestamps de logs, les champs exp/iat des JWT et les flux OAuth. Le rapport au temps Unix : ISO 8601 est la forme lisible d'un instant ; le temps Unix est la forme entière du même instant. Un convertisseur comme celui-ci passe de l'un à l'autre dans les deux sens. La forme heure locale (2026-05-03T14:30:00 sans décalage) est ambiguë et devrait être évitée dans tout système traversant des fuseaux horaires, elle est fréquemment à l'origine de bugs subtils dans lesquels une API JSON prétend renvoyer des timestamps mais ne précise pas dans quel fuseau.

Secondes vs millisecondes, la confusion la plus courante

Au niveau du système d'exploitation, le temps Unix compte des secondes: un entier à 10 chiffres pour tout instant entre environ 2001 et 2286 (les timestamps antérieurs à 2001 avaient 9 chiffres ou moins). Le Date.now() de JavaScript, le System.currentTimeMillis() de la JVM, le DateTimeOffset.ToUnixTimeMilliseconds() de .NET et la plupart des API web comptent en millisecondes: un entier à 13 chiffres pour la même plage. Les deux formes diffèrent d'exactement un facteur 1 000, et le bug le plus courant lié aux timestamps dans tout code parlant à plusieurs systèmes consiste à passer une valeur en millisecondes à une fonction qui attend des secondes (donnant une date 1 000× plus loin dans le futur que prévu) ou inversement (donnant une date à une fraction de seconde après l'epoch). Ce convertisseur détecte automatiquement selon le nombre de chiffres : 10 chiffres ou moins = secondes, 13 ou plus = millisecondes. Pour les valeurs entre les deux (11–12 chiffres, ambiguës), le convertisseur préfère l'interprétation qui donne une date plausible. Les microsecondes (16 chiffres, utilisées par certains systèmes haute précision et beaucoup de types TIMESTAMP de bases de données) et les nanosecondes (19 chiffres, utilisées par Linux clock_gettime, Go time.UnixNano(), l'outillage d'observabilité moderne comme OpenTelemetry) se rencontrent aussi mais sont moins courantes dans les données utilisateur.

Là où vous avez vraiment besoin de cette conversion

• Lecture de réponses d'API. Un endpoint REST renvoie "created_at": 1714665600: c'est quelle date ? Collez, lisez « 2 mai 2024 16:00:00 UTC », passez à la suite du débogage. Stripe, GitHub, AWS et la plupart des API d'entreprise utilisent des entiers temps Unix pour les champs de date précisément pour éviter l'ambiguïté de fuseau horaire.
• Décodage de timestamps de logs. Les logs serveur enregistrent souvent les heures sous forme d'entiers Unix pour la compacité et la rapidité de parsing. Lire « 1714665600.234 ERROR connection refused » exige de convertir le nombre de tête en heure calendaire pour corréler avec d'autres événements.
• Débogage de JWT. Les claims exp (expiration) et iat (émission) des JSON Web Tokens sont des entiers temps Unix selon la RFC 7519. Pour vérifier si un token est expiré ou voir quand il a été émis, collez la valeur ici.
• Calcul de différence temporelle. Soustrayez deux timestamps Unix pour obtenir la durée qui les sépare en secondes (ou millisecondes). Pas de calcul de fuseau, pas d'ajustement DST, pas de cas limites d'arithmétique calendaire.
• Requêtes de base de données avec colonnes epoch. Beaucoup de bases de données plus anciennes stockent les timestamps sous forme d'entiers Unix. Interroger « tous les événements entre X et Y » exige de convertir les dates limites lisibles en entiers Unix pour la clause WHERE.
• Planification et tâches cron. Les systèmes qui planifient des jobs à un instant absolu (Kubernetes CronJobs, AWS EventBridge, Azure Logic Apps) veulent souvent des cibles en temps Unix dans leur configuration. Convertissez l'heure cible lisible en epoch.
• Décodage de timestamps « intéressants ». Valeurs epoch célèbres : 0 = 1ᵉʳ janvier 1970 00 h 00 min 00 s UTC (l'epoch elle-même) ; 1234567890 = 13 février 2009 23 h 31 min 30 s UTC (brièvement célébré comme l'instant « Unix billion ») ; 1500000000 = 14 juillet 2017 02 h 40 min 00 s UTC ; 2000000000 = 18 mai 2033 03 h 33 min 20 s UTC ; 2147483647 = 19 janvier 2038 03 h 14 min 07 s UTC (le point de débordement Y2K38).

Une note sur les secondes intercalaires et le « vrai » temps

Une complication subtile : le temps Unix tel que défini par POSIX n'inclut pas les secondes intercalaires. Le temps universel coordonné (UTC) ajoute occasionnellement une seconde intercalaire pour maintenir le temps civil aligné sur la rotation réelle de la Terre, 27 secondes intercalaires ont été ajoutées depuis le démarrage du système en 1972. Le temps Unix fait comme si ces secondes intercalaires n'avaient pas eu lieu : quand une seconde intercalaire est insérée à la fin d'une journée, l'horloge soit répète la dernière seconde (comportement traditionnel de Linux), soit l'étale sur une période plus longue (l'approche « leap smear » de Google, adoptée par AWS et beaucoup de CDN). Pour la plupart des usages applicatifs, cela n'a pas d'importance, la précision sub-seconde est rarement significative au niveau application. Pour des travaux scientifiques de haute précision, des timestamps de systèmes de trading financier ou des timestamps à valeur probante en justice, le comportement vis-à-vis des secondes intercalaires est une source connue de cas limites. L'IERS (International Earth Rotation and Reference Systems Service) annonce les secondes intercalaires avec un préavis de six mois ; la plus récente a été insérée à la fin du 31 décembre 2016, et la communauté internationale a envisagé de retirer entièrement les secondes intercalaires (la résolution de le faire d'ici 2035 a été adoptée à la Conférence générale des poids et mesures de 2022).

Confidentialité : conversion uniquement dans le navigateur

Les timestamps que vous collez ne sont en général pas sensibles en eux-mêmes (un entier Unix ne révèle qu'un instant dans le temps), mais le contexte, une ligne de log contenant un identifiant utilisateur réel à côté du timestamp, un JWT contenant des claims sur un utilisateur réel, une réponse d'API avec des IDs internes, l'est fréquemment. Ce convertisseur tourne entièrement dans votre navigateur via l'API Date intégrée à JavaScript. Pas d'upload, pas de log, vérifiez dans l'onglet Réseau des DevTools pendant que vous tapez un timestamp (aucune requête ne part), ou mettez la page hors ligne (mode avion) après son chargement. L'affichage « now » en mise à jour continue utilise votre horloge locale, pas une source de temps réseau.

Questions fréquentes

Qu'est-ce qu'un timestamp Unix ?

Un timestamp Unix (aussi appelé temps Epoch ou temps POSIX) est le nombre de secondes écoulées depuis le 1ᵉʳ janvier 1970 à 00 h 00 min 00 s UTC, en suivant l'abstraction POSIX d'Unix (qui ne compte pas les secondes intercalaires) plutôt que les vraies secondes d'horloge atomique écoulées. Beaucoup de systèmes modernes utilisent des millisecondes plutôt que des secondes pour la précision sub-seconde (le Date.now() de JavaScript, le System.currentTimeMillis() de Java, le DateTimeOffset.ToUnixTimeMilliseconds() de .NET). Le temps Unix est la représentation temps standard dans pratiquement chaque système d'exploitation, base de données et API web.

Quelle différence entre secondes et millisecondes ?

Un facteur 1 000. Les timestamps Unix précision-secondes en 2026 ont 10 chiffres (par ex. 1714665600) ; précision-millisecondes 13 chiffres (par ex. 1714665600234). Ce convertisseur détecte automatiquement selon le nombre de chiffres. Le bug le plus courant dans le code mélangeant les deux formes consiste à passer des millisecondes à une fonction attendant des secondes (donnant une date 1 000× plus loin dans le futur que prévu) ou inversement.

Pourquoi mon heure convertie est-elle décalée de plusieurs heures ?

Le temps Unix est indépendant du fuseau horaire, mais sa forme lisible dépend du fuseau dans lequel vous l'affichez. Le convertisseur affiche trois formats simultanément : Heure locale (le fuseau de votre navigateur), UTC (Greenwich) et ISO 8601 (avec décalage explicite). Si le résultat ne correspond pas à ce que vous attendiez, vérifiez le fuseau, votre valeur « attendue » était probablement dans un fuseau différent du format que vous avez lu.

Quel est le problème Y2K38 ?

Si le temps Unix est stocké dans un entier signé sur 32 bits (le design Unix original), il déborde le 19 janvier 2038 à 03 h 14 min 07 s UTC. Les systèmes 64 bits modernes ne sont pas affectés, la date de débordement passe à environ l'an 292 milliards. Le risque Y2K38 est concentré dans les systèmes embarqués 32 bits encore en déploiement (automates industriels, satellites, infodivertissement automobile, back-ends bancaires, capteurs IoT à durée de vie pluri-décennale). Contrairement à Y2K, Y2K38 ne sera pas une crise d'un jour mais une série de petites pannes dans les systèmes de longue traîne au fil des années approchant 2038.

Cela fonctionne-t-il hors ligne ?

Oui, une fois la page chargée, toute la conversion s'exécute dans votre navigateur via l'API Date intégrée de JavaScript. Aucun appel réseau pendant l'usage. Le bouton « Now » utilise l'horloge locale de votre appareil ; le timestamp en mise à jour continue en haut se met à jour à partir de l'horloge système sans contacter de serveur de temps.

Outils associés