Comment convertir des horodatages Unix

Les horodatages Unix sont la façon dont les ordinateurs stockent et communiquent le temps : un nombre unique représentant les secondes depuis le 1er janvier 1970. Ils apparaissent dans les réponses API, les enregistrements de base de données, les fichiers journaux et les jetons JWT. Lorsque vous avez besoin de savoir quelle date est réellement 1711824000, vous avez besoin d'un convertisseur. Un convertisseur basé sur navigateur gère le calcul instantanément et vous permet d'aller dans les deux sens (horodatage vers date, date vers horodatage).

À quoi ressemble un horodatage Unix

La différence entre secondes et millisecondes est de trois zéros supplémentaires. Un nombre à 10 chiffres est en secondes ; 13 chiffres est en millisecondes. À partir de 2024, tous les horodatages Unix basés sur les secondes ont 10 chiffres et le resteront jusqu'en novembre 2286.

Comment convertir les horodatages

1. Entrez un horodatage ou une date : collez un horodatage Unix pour le convertir en date lisible, ou entrez une date pour obtenir l'horodatage.
2. Vérifiez le format : le convertisseur détecte automatiquement secondes vs millisecondes selon la longueur du nombre.
3. Lisez le résultat : voyez la date dans votre fuseau horaire local, UTC et au format ISO 8601.

Une brève histoire du temps Unix

Le temps Unix a été défini pour la première fois dans le Manuel du Programmeur Unix publié chez Bell Labs en novembre 1971. L'époque originale était le 1er janvier 1971, mais elle a été modifiée pour le 1er janvier 1970 peu après et normalisée dans POSIX.1 (1988).

Le choix de 1970 était arbitraire mais pratique : Unix a été développé en 1969-1971, et commencer le compte près de la naissance du système d'exploitation semblait raisonnable. Un entier signé 32 bits comptant les secondes à partir de 1970 donnait une plage de décembre 1901 à janvier 2038, ce que les concepteurs pensaient suffisant.

Ce ne l'est pas. Le « problème de l'an 2038 » (également appelé Y2K38) est le moment où les horodatages Unix signés 32 bits débordent : 2147483647 secondes après l'époque, le prochain tic-tac passe à un nombre négatif que les systèmes interprètent comme décembre 1901. La plupart des systèmes modernes ont migré vers des horodatages entiers 64 bits dans les années 2000 et 2010, mais certains appareils embarqués, anciennes bases de données et formats de fichiers hérités utilisent encore le temps 32 bits et nécessiteront des correctifs avant 2038.

Le temps Unix est désormais le standard de facto pour représenter le temps dans les systèmes informatiques. Les API JSON, les horodatages de lignes de base de données, les expirations JWT, les heures de bloc blockchain, les lectures de capteurs IoT : presque tous utilisent l'époque Unix directement ou indirectement.

Secondes, millisecondes, microsecondes, nanosecondes

Différents systèmes utilisent différentes précisions :

• Secondes (10 chiffres en 2024) : temps Unix classique, standard POSIX, la plupart des API et bases de données
• Millisecondes (13 chiffres) : JavaScript Date, Java System.currentTimeMillis(), nombreuses API web
• Microsecondes (16 chiffres) : PostgreSQL timestamp, Python datetime (après conversion)
• Nanosecondes (19 chiffres) : Go time.UnixNano(), traçage eBPF, systèmes de trading haute fréquence

Un horodatage à 19 chiffres peut confondre les convertisseurs s'attendant à des millisecondes ; vérifiez la documentation source lorsque vous voyez des nombres anormaux.

Où vous rencontrez les horodatages

• Réponses API : la plupart des API REST renvoient les dates sous forme d'horodatages Unix : "created_at": 1711824000
• Jetons JWT : les revendications iat (émis à) et exp (expiration) sont des horodatages Unix
• Enregistrements de base de données : de nombreuses bases de données stockent les horodatages sous forme d'entiers pour un tri et une comparaison efficaces
• Fichiers journaux : les journaux serveur préfixent souvent les entrées avec des horodatages epoch
• Taches Cron : les systèmes de planification référencent le temps au format Unix
• Mtime/atime/ctime du système de fichiers : les métadonnées de fichiers Linux et macOS utilisent le temps Unix
• Horodatages de bloc blockchain : chaque bloc Bitcoin et Ethereum a un horodatage Unix dans son en-tete
• Cookies et en-tetes HTTP : Max-Age, If-Modified-Since utilisent souvent indirectement les mathématiques d'époque

Horodatages dans le code

Conversion rapide dans les langages courants :

JavaScript :

new Date(1711824000 * 1000)            // Depuis secondes (multiplier par 1000)
new Date(1711824000000)                // Depuis millisecondes
Math.floor(Date.now() / 1000)          // Temps actuel en secondes
Date.now()                             // Temps actuel en millisecondes

Python :

from datetime import datetime, timezone
datetime.fromtimestamp(1711824000, tz=timezone.utc)
datetime.now(timezone.utc).timestamp()  # Temps actuel en secondes (float)

Bash :

date -u -d @1711824000                 # GNU date (Linux)
date -u -r 1711824000                  # BSD date (macOS)
date +%s                               # Temps actuel en secondes

SQL (PostgreSQL) :

SELECT TO_TIMESTAMP(1711824000);       -- Convertir epoch en timestamp
SELECT EXTRACT(EPOCH FROM NOW());      -- Epoch actuel

Go :

time.Unix(1711824000, 0)               // Depuis secondes
time.Now().Unix()                      // Temps actuel en secondes

Gestion des fuseaux horaires

C'est là que se cachent la plupart des bugs d'horodatage :

• Les horodatages Unix sont toujours en UTC. Il n'existe pas d'horodatage Unix « en heure locale ». Le nombre lui-meme est absolu.
• Le fuseau horaire d'affichage compte. Le meme horodatage 1711824000 s'affiche comme :
  • 2024-03-31 00:00:00 UTC
  • 2024-03-30 17:00:00 PDT (Los Angeles, UTC-7)
  • 2024-03-31 09:00:00 JST (Tokyo, UTC+9)
• Les transitions d'heure d'été sont délicates. Une heure locale comme « 2024-03-10 02:30:00 EST » n'existe pas (l'horloge a sauté de 02:00 à 03:00). Les convertisseurs gèrent cela différemment ; certains renvoient une erreur, certains arrondissent à 03:30, certains basculent en heure standard.
• Les secondes intercalaires sont ignorées. Le temps Unix prétend que chaque minute a exactement 60 secondes. L'UTC réel insère des secondes intercalaires occasionnellement (la dernière était en 2016). Pour 99% des utilisations c'est bien ; pour l'astronomie de précision ou les horloges atomiques c'est important.

Lors de l'envoi d'horodatages dans les API, utilisez toujours les secondes UTC. Lors de l'affichage aux utilisateurs, convertissez dans leur fuseau horaire local. Le convertisseur gère les deux directions.

Pièges courants

• Le constructeur JavaScript Date() prend des millisecondes, pas des secondes : le bug d'horodatage n°1. new Date(1711824000) interprète le nombre comme le 20 janvier 1970 parce que JS le lit comme millisecondes. Vous avez besoin de new Date(1711824000 * 1000).
• Confondre le temps Unix et les numéros de date Excel/Google Sheets : Excel utilise une époque différente (30 décembre 1899) et compte les jours, pas les secondes. Importer un horodatage Unix dans une colonne de date affichera la mauvaise date.
• Horodatages négatifs : les dates antérieures au 1er janvier 1970 sont représentées comme des horodatages Unix négatifs. Certains convertisseurs et bases de données les rejettent ; d'autres les gèrent correctement.
• An 2038 dans le code hérité : les horodatages entiers signés 32 bits débordent le 19 janvier 2038 à 03:14:07 UTC. La plupart des systèmes modernes utilisent 64 bits, mais vérifiez les appareils embarqués, les anciennes bases de données SQLite et les systèmes d'exploitation 32 bits.
• Analyse de date dépendante de la locale : « 03/04/2024 » est le 4 mars en anglais américain, le 3 avril en anglais britannique. Passez toujours des horodatages (ou des chaines ISO 8601) entre systèmes ; jamais de chaines formatées par locale.
• Perte de précision sous-seconde : stocker un horodatage en millisecondes dans un champ de précision secondes perd les 3 derniers chiffres. Certaines API renvoient les deux formats (created_at en secondes, created_at_ms en millisecondes) pour éviter cela.

Conseils

• Multipliez par 1000 pour JavaScript : JS Date attend des millisecondes, mais la plupart des API renvoient des secondes. Oublier de multiplier est le bug d'horodatage le plus courant.
• Spécifiez toujours UTC : lors de la conversion, soyez explicite sur le fuseau horaire. « 31 mars à minuit » est un horodatage différent selon que vous voulez dire UTC, EST ou PST.
• Utilisez ISO 8601 pour l'affichage : une fois converti, formatez les dates comme 2024-03-31T00:00:00Z pour une communication sans ambiguité entre fuseaux horaires.
• Mettez le convertisseur en favori : si vous travaillez avec des API ou des bases de données, vous convertirez des horodatages assez souvent pour le vouloir à un clic.
• Aller-retour pour vérifier : en cas de doute, convertissez votre horodatage en date, puis convertissez la date en horodatage. Si vous obtenez le meme nombre, votre compréhension est correcte.
• Surveillez le nombre de chiffres : 10 = secondes, 13 = millisecondes, 16 = microsecondes, 19 = nanosecondes. Si vos calculs sont décalés d'un facteur 1000 ou 1000000, vous avez une discordance de précision.

Confidentialité

Le convertisseur d'horodatage Unix fonctionne entièrement dans votre navigateur. Les horodatages et dates que vous entrez ne quittent jamais votre appareil. Cela importe parce que les horodatages peuvent etre sensibles : ils peuvent provenir de fichiers journaux révélant la chronologie de l'infrastructure interne, des jetons JWT avec des informations utilisateur/session intégrées, du débogage d'API interne qui ne devrait pas etre partagé avec des tiers. Les convertisseurs d'horodatage en nuage peuvent enregistrer les entrées à des fins « d'amélioration » ; un convertisseur basé sur navigateur n'a aucune exposition.

La conversion basée sur navigateur fonctionne également hors ligne une fois la page chargée, et est assez rapide pour que vous puissiez déposer un horodatage dans le champ et voir la date dans le meme moment.