Dernière mise à jour : 2026-06-28

Horodatage Unix (Epoch ⇄ Date)

Un horodatage Unix est un entier représentant le nombre de secondes écoulées depuis le 1970-01-01 00:00:00 UTC, moment conventionnellement appelé « epoch Unix ». Cette représentation est indépendante des fuseaux horaires et des calendriers locaux, ce qui en fait le moyen standard par lequel les systèmes informatiques encodent des instants dans le temps. Ce convertisseur effectue la transformation dans les deux sens : d'une valeur epoch vers une date UTC lisible, et d'une date vers sa valeur epoch correspondante.

Définition et origine de l'epoch Unix

Le point de départ, le 1er janvier 1970 à minuit UTC, est une convention héritée des premiers travaux sur Unix aux laboratoires Bell dans les années 1960. Ce choix était arbitraire : il s'agissait simplement d'une date récente, facile à mémoriser, permettant de compter des instants futurs sans recourir à de grands entiers. La convention s'est ensuite répandue via le standard POSIX, puis dans la quasi-totalité des systèmes d'exploitation et des langages de programmation actuels.

Un horodatage de 0 désigne l'epoch elle-même. Un horodatage de 86 400 désigne exactement un jour plus tard (60 secondes × 60 minutes × 24 heures). Les valeurs négatives sont valides et représentent des moments antérieurs à 1970.

Secondes et millisecondes

Le standard Unix original compte des secondes entières. Les outils Unix classiques — journaux de serveur, enregistrements en base de données, utilitaires shell — utilisent des horodatages en secondes, produisant des valeurs à 10 chiffres pour les dates des années 2000 à 2030.

JavaScript a introduit une variante à la milliseconde près : Date.now() et Date.getTime() renvoient le nombre de millisecondes depuis l'epoch, produisant des valeurs à 13 chiffres. De nombreuses interfaces REST, flux d'événements et bases de données orientées JavaScript suivent cette convention.

Ordre de grandeur pratique : un nombre à 10 chiffres est presque certainement en secondes ; un nombre à 13 chiffres est presque certainement en millisecondes. Pour convertir des millisecondes en secondes, il suffit de diviser par 1 000 — ce convertisseur effectue cette opération automatiquement lorsque l'unité « millisecondes » est sélectionnée.

Mécanisme de conversion

De l'epoch vers la date. Étant donné un horodatage $t$ en secondes, la date et l'heure UTC s'obtiennent par :

Le nombre de jours est ensuite converti en date du calendrier grégorien en tenant compte des années bissextiles. L'heure du jour est décomposée en heures, minutes et secondes par division modulaire successive.

De la date vers l'epoch. Pour une date donnée à minuit UTC, l'epoch s'obtient en comptant le nombre de jours depuis le 1970-01-01 et en multipliant par 86 400. Par exemple, pour le 2024-01-01, le nombre de jours est 19 723, ce qui donne :

$19\,723 \times 86\,400 = 1\,704\,067\,200 \text{ s}$

Ce convertisseur gère les années bissextiles et les cas limites du calendrier en s'appuyant sur les fonctions de date intégrées de l'environnement d'exécution.

Le problème de l'an 2038

De nombreux systèmes anciens stockent les horodatages Unix sous forme d'entier signé sur 32 bits. La valeur maximale d'un tel entier est 2 147 483 647, correspondant au 2038-01-19 03:14:07 UTC. Passé cet instant, le compteur déborde et revient à la valeur négative la plus grande, que ces systèmes interpréteraient comme une date en décembre 1901.

Les systèmes modernes en 64 bits ne sont pas affectés : un entier signé sur 64 bits peut représenter des horodatages couvrant des centaines de milliards d'années. Le problème de l'an 2038 est donc propre aux systèmes embarqués non mis à jour, à certaines bases de données anciennes et aux bibliothèques logicielles non maintenues. La plupart des systèmes d'exploitation courants et des langages de programmation ont migré vers le temps en 64 bits avant 2020.

Points de vigilance courants

Fuseaux horaires. Un horodatage Unix compte toujours les secondes depuis le 1970-01-01 à minuit UTC. Il n'encode pas de fuseau horaire. Pour convertir une heure locale en epoch, il faut d'abord la ramener en UTC. Ce convertisseur utilise minuit UTC comme référence pour les entrées sous forme de date, conformément à l'interprétation standard.

Secondes intercalaires. L'epoch Unix ne tient pas compte des secondes intercalaires : elle suppose exactement 86 400 secondes par jour. Les horodatages Unix ne sont donc pas strictement équivalents au Temps Atomique International (TAI). Pour les usages logiciels courants, cet écart — d'environ 27 secondes cumulées à fin 2024 — est sans conséquence pratique.

Débordement entier dans du code ancien. Même si le système d'exploitation hôte utilise le temps en 64 bits, des bibliothèques tierces, des types de colonnes en base de données ou des formats de sérialisation peuvent encore stocker les horodatages sur 32 bits. Lors d'échanges avec des systèmes externes, il convient de vérifier la largeur de stockage si la précision au-delà de 2038 est importante.