En quoi consiste cet outil ?
Un horodatage Unix (également appelé « époque ») correspond au nombre de secondes écoulées depuis le 1er janvier 1970 à 00 h 00 min 00 s UTC. Il s'agit de la méthode standard utilisée par les ordinateurs pour enregistrer des moments précis : les bases de données, les fichiers journaux, les API et les langages de programmation l'utilisent tous, car il s'agit d'un nombre unique et sans ambiguïté, qui évite toute confusion liée au fuseau horaire.
Il existe deux formats : les secondes (10 chiffres aujourd'hui, par exemple 1720500000) et les millisecondes (13 chiffres, utilisées par JavaScript et Java). Cet outil détecte automatiquement le format que vous avez collé.
Pourquoi l'utiliser ?
- Lisez instantanément les horodatages issus des journaux, des lignes de base de données et des réponses API.
- Détecte automatiquement les secondes et les millisecondes — pas besoin de deviner.
- Affiche simultanément l'heure locale, l'heure UTC, l'heure au format ISO 8601 et l'heure relative (« il y a 3 heures »).
- Convertir dans les deux sens : horodatage → date et date → horodatage.
- Horloge en temps réel indiquant l'époque actuelle, pour une consultation rapide.
Mode d'emploi
- Pour décoder : collez un horodatage (par exemple 1720500000) dans le champ de gauche, puis cliquez sur « Convertir ».
- Affichez le résultat dans votre fuseau horaire local, en UTC, au format ISO 8601 et sous forme d'heure relative.
- Pour effectuer la conversion : sélectionnez une date et une heure dans le champ de droite, puis cliquez sur « Convertir » pour obtenir l'horodatage correspondant en secondes et en millisecondes.
- Utilisez l'horloge en temps réel située en haut de la page lorsque vous avez simplement besoin de l'horodatage actuel.
Exemple
Entrée
1720500000Résultat
Heure locale : 09/07/2024, 13:20:00
Heure UTC : mar. 09 juil. 2024 05:20:00 GMT
ISO 8601 : 2024-07-09T05:20:00.000ZUne valeur à 10 chiffres correspond à des secondes ; une valeur à 13 chiffres correspond à des millisecondes.
Conseils pratiques
- Débogage des bugs liés à une « heure erronée » : dans 90 % des cas, il s'agit de problèmes d'affichage du fuseau horaire, et non d'horodatages erronés. Comparez la ligne « UTC » avec les journaux de votre serveur (les serveurs enregistrent généralement l'heure en UTC) avant de modifier le code.
- Une date correspondant exactement au 01/01/1970 signifie que l'horodatage était égal à 0 ou manquant — un symptôme classique d'une valeur nulle, et non une date réelle.
- Une date autour de 1970 + quelques jours signifie généralement que les secondes ont été interprétées comme des millisecondes à un certain endroit ; une date supérieure à 56 000 signifie l'inverse.
- Dans les tableurs : Excel compte les jours depuis 1900, et non les secondes depuis 1970. Pour obtenir un horodatage en secondes, utilisez la formule suivante : =(A1/86400)+DATE(1970,1,1).
Scénarios d'utilisation concrets
Les cas concrets où les horodatages prennent toute leur importance : lecture des champs d'expiration dans les JWT et les jetons API (exp/iat sont exprimés en secondes Unix), mise en corrélation de l'heure d'un rapport de bogue d'un utilisateur avec les lignes du journal du serveur, définition des durées de vie (TTL) du cache et des fenêtres de cron, et vérification de l'expiration effective d'un certificat ou d'un jeton. La ligne indiquant le temps relatif (« il y a 3 heures ») constitue le moyen le plus rapide de vérifier la validité de tous ces éléments.
Le débogage des JWT est suffisamment courant pour qu'il vaille la peine de l'expliquer en détail : décodez la charge utile du jeton à l'aide de l'outil Base64, puis collez la valeur « exp » ici — vous obtiendrez ainsi instantanément la réponse à la question « ce jeton est-il périmé et depuis combien de temps ? ».
Pourquoi le temps Unix a-t-il été conçu ainsi ?
Le fait de stocker un simple nombre croissant à partir d’une époque fixe (plutôt qu’une structure année/mois/jour/heure) relevait d’un choix délibéré en faveur de la simplicité : deux horodatages peuvent être comparés ou soustraits à l’aide d’opérations arithmétiques simples, sans nécessiter de logique calendaire. C’est pourquoi les bases de données, les formats de journaux et la représentation interne de la date dans pratiquement tous les langages de programmation s’appuient sur ce principe. Le coût de cette simplicité est précisément ce que cet outil vise à atténuer : les humains ne pensent pas en « secondes depuis 1970 », chaque horodatage doit donc être converti en une date calendaire avant de prendre tout son sens pour la personne qui le lit, et cette conversion doit tenir compte à la fois du fuseau horaire, de la précision (secondes ou millisecondes) et du format d’affichage.
Foire aux questions
Comment l'outil sait-il si mon horodatage est exprimé en secondes ou en millisecondes ?
En fonction de la valeur. Les valeurs égales ou supérieures à 1 000 000 000 000 (1e12) sont considérées comme des millisecondes ; les valeurs inférieures sont considérées comme des secondes. Les dates actuelles correspondent à environ 1,7 milliard de secondes et environ 1 700 milliards de millisecondes ; les deux plages ne se chevauchent donc pas pour les dates réalistes.
Pourquoi l'horodatage indique-t-il une heure différente de celle à laquelle je m'attendais ?
Fuseaux horaires. Un horodatage est toujours exprimé en UTC ; la ligne « heure locale » le convertit dans le fuseau horaire de votre appareil. Comparez la ligne UTC avec les informations enregistrées par votre système source — de nombreux serveurs enregistrent leurs journaux en UTC.
Qu'est-ce que le « problème de l'année 2038 » ?
Les systèmes qui stockent les horodatages sous forme d'entiers signés de 32 bits subiront un débordement le 19 janvier 2038. Les systèmes modernes utilisent des entiers de 64 bits et ne sont donc pas concernés. Cet outil utilise les nombres JavaScript, qui prennent en charge des dates bien au-delà de 2038.
Puis-je convertir des horodatages négatifs ?
Oui. Les horodatages négatifs correspondent à des dates antérieures au 1er janvier 1970 ; par exemple, -86 400 correspond au 31 décembre 1969.
Cette époque inclut-elle les secondes intercalaires ?
Non. Le temps Unix part du principe que chaque jour compte exactement 86 400 secondes et ne tient pas compte des secondes intercalaires — une simplification délibérée qui facilite les calculs.