L'horodatage Unix expliqué: secondes, millisecondes, fuseaux horaires et 2038

Ouvrez presque n'importe quel fichier journal, table de base de données ou réponse API et vous trouverez des numéros comme 1760000000. C'est un horodatage Unix: le nombre de secondes écoulées depuis 00:00:00 UTC le 1er janvier 1970, connu sous le nom d'époque Unix. C'est la façon la plus courante dont les ordinateurs représentent un moment dans le temps, et sa compréhension empêche toute une classe de bugs impliquant les fuseaux horaires, l'été et l'analyse des dates.

Pourquoi compter les secondes à partir de 1970 ?

Les premiers développeurs Unix avaient besoin d'une représentation simple et compacte du temps. Le comptage des secondes à partir d'une date récente fixe s'intègre dans un seul entier, est facile à comparer et à soustraire et évite la complexité des calendriers. La date du 1er janvier 1970 était simplement un point de départ rond pratique lorsque Unix était en cours de construction.

Les avantages sont toujours valables aujourd'hui:

• ** indépendant du fuseau horaire.** Un horodatage identifie un instant, pas une lecture d'horloge murale. Le même événement a le même horodatage à Tokyo, Berlin et São Paulo.
• Arithmétique facile. La différence entre deux horodatages est une durée en secondes. Ajoutant 86 400 mouvements en avant par jour.
• Compact et triable. Un entier prend 8 octets et est trié chronologiquement.
• Non équivoque. Aucune confusion entre 03/04 signifiant 4 mars ou 3 avril.

Secondes contre millisecondes

Le problème le plus fréquent avec l'horodatage est le mélange des unités:

• Les outils Unix, la plupart des bases de données, JWT et de nombreuses API utilisent secondes: 10 chiffres aujourd'hui, comme 1760000000.
• Date.now() de JavaScript, System.currentTimeMillis() de Java et de nombreux systèmes d'analyse utilisent des millisecondes: 13 chiffres, tels que 1760000000000.
• Certains systèmes utilisent des microsecondes (16 chiffres) ou des nanosecondes (19 chiffres).

L'interprétation des millisecondes en secondes donne une date de dizaines de milliers d'années dans le futur; l'inverse vous amène en janvier 1970. Si jamais vous voyez "1970-01-21" dans une interface utilisateur, quelqu'un a passé des secondes où des millisecondes étaient attendues. Un [convertisseur d'horodatage] ((/outils/horodatage) détecte l'unité par longueur, ce qui est une vérification rapide de la santé mentale.

Conversion des horodatages en langues communes

Le code de l'appareil

const nowSeconds = Math.floor(Date.now() / 1000);
const date = new Date(1760000000 * 1000);
date.toISOString(); // "2025-10-09T08:53:20.000Z"

Je suis un Python.

import time, datetime
now = int(time.time())
dt = datetime.datetime.fromtimestamp(1760000000, tz=datetime.timezone.utc)

Passez toujours tz= dans Python; sans cela, fromtimestamp renvoie une heure locale naïve qui est facile à mal interpréter.

**SQL (PostgreSQL) **

SELECT to_timestamp(1760000000);           -- timestamptz
SELECT extract(epoch FROM now())::bigint;  -- current Unix time

Je vous en prie.

t := time.Unix(1760000000, 0).UTC()
now := time.Now().Unix()

Une coquille

date +%s                    # current timestamp
date -u -d @1760000000      # GNU date
date -u -r 1760000000       # macOS/BSD date

Fuseaux horaires: stocker UTC, afficher le local

Un horodatage n'a pas de fuseau horaire; c'est un instant absolu. Des problèmes surviennent lors de la conversion vers et à partir de dates lisibles par l'homme:

• ** Partage d'une date sans zone.** new Date("2026-03-29 02:30") est interprété dans le fuseau horaire local de la machine qui exécute le code. Sur un serveur en UTC et un ordinateur portable à Berlin, il produit des horodatages différents.
• Les écarts et les chevauchements de l'heure d'été. Dans les zones avec l'heure d'été, certaines heures locales n'existent pas (les horloges sautent en avant) et d'autres se produisent deux fois (les horloges reculent). Un horodatage n'a pas une telle ambiguïté.
• Enregistrement des heures locales. Si vous enregistrez "2026-11-01 01:30" sans zone, vous ne pouvez jamais être sûr de l'instant.

La règle de base: stocker et transmettre des horodatages ou des chaînes ISO 8601 avec un décalage explicite (2026-10-11T09:30:00Z ou +02:00). Convertir à la zone locale de l'utilisateur uniquement lors de l'affichage. Stockez le nom du fuseau horaire IANA de l'utilisateur (comme Europe/Berlin) séparément si vous devez planifier les choses à l'heure locale.

ISO 8601 par rapport aux horodatages Unix

Les chaînes ISO 8601 comme 2026-10-11T09:30:00Z sont lisibles par l'homme et également sans ambiguïté lorsqu'elles incluent Z ou un décalage. Beaucoup d'API les préfèrent pour leur lisibilité. Les horodatages Unix sont plus petits et plus rapides à comparer. Les deux sont bons; l'important est la cohérence et toujours l'inclusion des informations sur les zones.

Secondes bissextiles

La rotation de la Terre est légèrement irrégulière, de sorte que l'UTC officiel insère parfois une seconde bissextile. Le temps Unix les ignore: chaque jour est exactement 86 400 secondes, et pendant une seconde bissextile l'horodatage se répète ou est effacé. Pour presque toutes les applications, cela est invisible. Si vous travaillez sur un chronométrage de haute précision, utilisez plutôt le temps TAI ou GPS. Les organismes internationaux de chronométrage ont décidé d'éliminer progressivement les secondes bissextiles d'ici 2035, ce qui rendra cela encore moins préoccupant.

Le problème de l'année 2038

De nombreux systèmes plus anciens stockent le temps Unix sous forme d'un entier signé de 32 bits, dont la valeur maximale est de 2 147 483 647. Cela correspond à 03:14:07 UTC le 19 janvier 2038. Une seconde plus tard, la valeur déborde à −2.147.483.648, ce qui représente le 13 décembre 1901.

Les systèmes d'exploitation, les langages et les bases de données modernes à 64 bits utilisent des horodatages à 64 bits, qui ne déborderont pas avant environ 292 milliards d'années. Les risques demeurent:

• Appareils intégrés et contrôleurs industriels avec une longue durée de vie.
• Formats de fichiers et protocoles réseau avec des champs de temps de 32 bits.
• Colonnes de base de données déclarées comme INT de 32 bits contenant des secondes d'époque. Le type TIMESTAMP de MySQL a une limite de 2038; DATETIME ou BIGINT non.

Vérifiez les données à longue durée de vie maintenant, en particulier tout ce qui stocke des dates futures telles que l'expiration du certificat ou les contrats de 20 ans.

Marquage horaire négatif

Les dates antérieures à 1970 ont des horodatages négatifs. -86400 est le 31 décembre 1969. La plupart des langages modernes les traitent correctement, mais certaines API et feuilles de calcul plus anciennes ne le font pas, alors testez explicitement les dates historiques.

Liste de contrôle pratique de débogage

1. Comptez les chiffres: 10 pour les secondes, 13 pour les millisecondes.
2. Convertissez d'abord en UTC, puis en heure locale, pour séparer les bugs unitaires des bugs de zone.
3. Vérifiez si une chaîne de dates inclut Z ou un décalage avant de l'analyser.
4. Comparez les horloges serveur et client si les jetons ou les signatures échouent avec des erreurs "expirées" ou "pas encore valides" voir comment fonctionne JWT pour savoir pourquoi exp et nbf sont des secondes Unix.
5. Lorsque vous planifiez des tâches récurrentes, rappelez-vous que cron s'exécute dans la zone du serveur; ces exemples de cron couvrent les détails.

Résumé

Un horodatage Unix est le nombre de secondes depuis 1970-01-01 UTC. Il est simple, indépendant du fuseau horaire et facile à calculer. La plupart des bugs proviennent du mélange de secondes et de millisecondes, de l'analyse des dates sans zones ou du stockage des heures locales. Enregistrez l'UTC, convertissez aux bords, utilisez des entiers 64 bits, et vous n'aurez plus jamais à penser à l'heure.