Convertisseur d'horodatage Unix

Convertisseur d'horodatage Unix

Convertissez instantanément entre les horodatages Unix (epoch) et les dates et heures lisibles. Cet outil est utilisé quotidiennement par les développeurs logiciels qui déboguent des fichiers journaux, les administrateurs de bases de données qui lisent des horodatages stockés, les analystes de données qui traitent des réponses d'API, et toute personne ayant besoin de savoir précisément à quel moment correspond un nombre à 10 chiffres comme 1746057600.

Comment fonctionne la conversion d'horodatage Unix

Un horodatage Unix est un compteur de secondes écoulées depuis l'epoch Unix -- le 1er janvier 1970, 00:00:00 UTC. Chaque seconde qui passe incrémente l'horodatage de 1.

Horodatage vers date -- le total de secondes est converti en soustrayant d'abord les années (en tenant compte des années bissextiles de 365 et 366 jours), puis les mois (de longueur variable), puis les jours, les heures, les minutes et les secondes restantes. Le résultat est toujours en UTC ; afficher l'heure locale nécessite d'ajouter ou de soustraire le décalage du fuseau horaire en secondes.

Date vers horodatage -- on additionne tous les composants depuis l'epoch : années x 31 536 000 (ajustées pour les années bissextiles) + jours du mois x 86 400 + heures x 3 600 + minutes x 60 + secondes. Exemple : le 1er janvier 2025, 00:00:00 UTC = 1 735 689 600.

Secondes contre millisecondes -- la méthode Date.now() de JavaScript et de nombreuses API REST renvoient des millisecondes depuis l'epoch (un nombre à 13 chiffres comme 1 735 689 600 000). Le temps Unix standard utilise des secondes (10 chiffres). Divisez les millisecondes par 1 000 pour obtenir des secondes ; multipliez les secondes par 1 000 pour obtenir des millisecondes.

Exemples concrets

Exemple 1 -- Lecture d'un journal de serveur. Un journal d'accès nginx affiche une requête à l'horodatage 1700000000. Conversion : 1 700 000 000 secondes / 86 400 = 19 675,9 jours après le 1er janvier 1970 = le 14 novembre 2023, 22:13:20 UTC. Dans le fuseau Est des États-Unis (UTC-5), cela correspond au 14 novembre 2023, à 17:13:20.

Exemple 2 -- En-tête de limite de débit d'une API. Une réponse de l'API GitHub inclut X-RateLimit-Reset: 1746057600. Conversion : il s'agit du 30 avril 2025, 16:00:00 UTC. Si l'heure actuelle est 15:45 UTC, la limite de débit se réinitialise dans 15 minutes.

Exemple 3 -- Arithmétique d'horodatage en base de données. Une session utilisateur stockée dans PostgreSQL a commencé à created_at = 1735689600 et a expiré à 1735693200. La différence est de 3 600 secondes, soit exactement 1 heure. L'arithmétique sur les horodatages se résume à une simple soustraction, sans bibliothèque de dates nécessaire.

Tableau de référence

Quand l'utiliser

• Décoder des horodatages dans des journaux de serveur, des rapports de plantage ou des tableaux de bord de supervision où les événements sont stockés sous forme d'entiers.
• Convertir des champs de réponse d'API (expiration JWT, expiration de jeton OAuth, horodatages de webhook) en dates lisibles pour faciliter le débogage.
• Générer un horodatage Unix futur ou passé à utiliser dans une requête de base de données, un appel d'API ou une tâche planifiée.
• Calculer l'écart de temps entre deux événements stockés sous forme d'horodatages Unix en soustrayant l'un de l'autre.
• Vérifier qu'un horodatage provenant d'un système tiers correspond bien à la date attendue avant de l'utiliser en production.

Erreurs fréquentes

1. Confondre secondes et millisecondes. Un horodatage à 10 chiffres comme 1700000000 est exprimé en secondes ; un horodatage à 13 chiffres comme 1700000000000 est exprimé en millisecondes. Traiter un horodatage en millisecondes comme s'il était en secondes donne une date 1 000 fois trop éloignée dans le futur -- le nombre 1700000000000 interprété comme des secondes correspondrait à l'année 55 000. Vérifiez toujours le nombre de chiffres : 10 chiffres = secondes, 13 chiffres = millisecondes.
2. Afficher un horodatage UTC comme s'il s'agissait de l'heure locale sans conversion. Un horodatage de 1700000000 correspond au 14 novembre 2023, à 22:13:20 UTC. À New York (UTC-5 en novembre), il est 17:13. Afficher l'heure UTC à un utilisateur new-yorkais sans préciser qu'il s'agit d'UTC crée des écarts déroutants de 5 heures.
3. Supposer que tous les systèmes utilisent la même précision d'horodatage. La fonction time.time() de Python renvoie des secondes avec des décimales fractionnaires (par exemple, 1700000000.123456). Date.now() de JavaScript renvoie des millisecondes entières. UNIX_TIMESTAMP() de MySQL renvoie des secondes entières. Mélanger ces valeurs sans les normaliser provoque des erreurs de comparaison décalées d'un facteur 1 ou 1 000.
4. Ignorer les horodatages négatifs. Les horodatages Unix antérieurs au 1er janvier 1970 sont négatifs. L'horodatage -86400 correspond au 31 décembre 1969, à 00:00:00 UTC. Certains systèmes et bibliothèques plus anciens ne gèrent pas correctement les horodatages négatifs et peuvent renvoyer des erreurs ou des dates incorrectes pour toute date antérieure à 1970.

Repères de référence rapide

Constantes utiles pour des calculs rapides d'horodatage :

Astuces

1. Un horodatage Unix à 10 chiffres commençant par 17 correspond à une date allant de fin 2023 à environ mi-2027. Un horodatage commençant par 16 se situe entre 2020 et 2023. Utilisez les premiers chiffres comme vérification rapide de cohérence.
2. Pour obtenir l'horodatage Unix actuel : JavaScript -- Math.floor(Date.now() / 1000), Python -- int(time.time()), Bash -- date +%s, SQL (MySQL) -- UNIX_TIMESTAMP(), SQL (PostgreSQL) -- EXTRACT(EPOCH FROM NOW()).
3. Pour trouver l'horodatage correspondant à minuit UTC pour une date donnée, saisissez la date à 00:00:00 UTC. Les horodatages de minuit sont toujours divisibles par 86 400.
4. Stockez tous les horodatages de votre base de données en UTC. Ne convertissez vers le fuseau horaire local de l'utilisateur qu'au niveau de l'affichage. Cela évite les bugs lorsque les utilisateurs changent de fuseau horaire ou lors des transitions d'heure d'été.
5. Le bug de l'an 2038 affecte les horodatages en entier signé 32 bits, qui plafonnent à 2 147 483 647 (19 janvier 2038, 03:14:07 UTC). Si votre système stocke encore les horodatages en entiers 32 bits, prévoyez une migration vers des entiers 64 bits avant 2038.
6. Lorsque vous comparez deux horodatages provenant de systèmes différents, vérifiez qu'ils utilisent la même epoch. La plupart des systèmes utilisent le 1er janvier 1970, mais le format FILETIME de Windows utilise le 1er janvier 1601, et le protocole NTP utilise le 1er janvier 1900. Pour convertir entre epochs, il faut ajouter ou soustraire la différence en secondes entre les deux dates de référence.