FlowingDev

Le temps Epoch, expliqué : L'horloge qui ne fait qu'avancer

Découvrez ce qu'est le temps Unix (ou temps Epoch) : le nombre de secondes écoulées depuis le 1er janvier 1970, utilisé par les ordinateurs pour suivre le temps de manière universelle.

Essayer l'outil: Convertisseur d'époque

En une phrase

Le temps Epoch est la façon qu'a un ordinateur de suivre le temps sous la forme d'un nombre unique et toujours croissant : le nombre total de secondes écoulées depuis le 1er janvier 1970 à minuit UTC.

Le problème que ça résout

Les humains et le temps, c'est une relation compliquée. On a les fuseaux horaires, le passage à l'heure d'été/hiver, et des formats comme MM/JJ/AAAA contre JJ/MM/AAAA. On écrit « 8 octobre 2024 à 15h00 », mais ça veut dire une chose à Tokyo et une autre à Toronto. C'est un bordel d'ambiguïté.

Les ordinateurs, à l'inverse, détestent l'ambiguïté. Ils ont besoin d'une manière unique, universelle et mathématiquement simple de représenter un instant T. Essayer de faire des calculs avec « 8 octobre », c'est un cauchemar. Mais faire des maths avec un bon vieux nombre ? C'est pour ça que les ordis sont faits.

C'est le problème que le temps Unix (aussi appelé temps Epoch ou temps POSIX) a été créé pour résoudre. À l'aube du système d'exploitation Unix dans les années 70, ses créateurs avaient besoin d'un système simple pour garder la notion du temps. Ils ont décidé de choisir un point de départ arbitraire — une « epoch » — et de simplement... compter.

L'epoch choisie fut 00:00:00 UTC, le 1er janvier 1970. Pourquoi cette date ? C'était un chiffre bien rond, et c'était assez récent pour la technologie de l'époque.

À partir de ce moment, chaque seconde qui passe incrémente un compteur universel. Donc, au lieu qu'un ordinateur ait à parser « 15h00 le 8 octobre 2024, à Toronto (qui est en EDT) », il peut juste stocker le nombre 1728409200. Ce nombre représente ce moment exact dans le temps, partout sur Terre, simultanément. Pas de fuseaux horaires, pas de formats, pas de « c'est le matin ou l'après-midi ? ». Juste un nombre. Problème résolu.

Comment ça marche sous le capot

À la base, le concept est simplissime. Mais comme pour tout en tech, le diable est dans les détails.

L'Epoch et l'unité

Le système entier repose sur deux idées :

  1. Le point de départ (Epoch) : Il est fixé au 1970-01-01T00:00:00Z. Le Z signifie Zoulou, un terme militaire et aéronautique pour UTC (Temps Universel Coordonné). Dans le monde du temps Epoch, ce moment est simplement 0.
  2. L'unité de mesure : L'unité standard et officielle est la seconde.

Ainsi, le timestamp 1 représente 1970-01-01T00:00:01Z. Le timestamp pour le début du jour suivant, 1970-01-02T00:00:00Z, est 86400 (car il y a 60 secondes * 60 minutes * 24 heures = 86 400 secondes dans une journée).

// Une date lointaine dans le futur
const humanDate = new Date('2035-10-26T10:00:00Z');

// Son timestamp Epoch correspondant en secondes
const epochTimestamp = 2071754400;

Quand votre ordinateur vous affiche ce timestamp en heure locale, il fait une conversion en coulisses. Il prend le timestamp UTC universel et applique le décalage de fuseau horaire de votre système pour l'afficher d'une manière qui a du sens pour vous. Le nombre sous-jacent, cependant, reste pur et universel.

Variations : millisecondes, microsecondes, nanosecondes

Parfois, on a besoin de mesurer des choses qui se passent plus vite qu'une seconde. Pour cela, les systèmes utilisent des versions plus précises du timestamp Epoch. Le principe est le même, mais l'unité change.

Unité Exemple de valeur (pour le même instant) Nombre de chiffres courant Cas d'usage typique
Secondes 1728409200 10 Le standard POSIX ; APIs, bases de données.
Millisecondes 1728409200123 13 JavaScript (Date.now()), APIs modernes.
Microsecondes 1728409200123456 16 Systèmes haute performance, certaines bases de données.
Nanosecondes 1728409200123456789 19 Calcul scientifique, langage Go.

C'est la source de bugs numéro un quand on travaille avec des timestamps. Si un système vous donne un nombre à 13 chiffres et que vous le traitez comme des secondes, vous essayez de calculer une date dans des milliers d'années. Vérifiez toujours la doc ou regardez le nombre de chiffres pour savoir à quoi vous avez affaire.

Le « problème de l'an 2038 »

Voici un grand classique du folklore informatique. Beaucoup de vieux systèmes, pour économiser de la précieuse mémoire, stockaient le timestamp Epoch sous forme d'un entier signé de 32 bits.

Un « bit » est un 1 ou un 0. « 32 bits » veut dire que vous avez 32 emplacements pour des 1 et des 0. « Signé » signifie qu'un de ces bits est utilisé pour indiquer si le nombre est positif ou négatif. Ça laisse 31 bits pour le nombre lui-même, qui peut représenter une valeur maximale de 2^31 - 1, soit 2 147 483 647.

Que se passe-t-il quand le nombre de secondes depuis 1970 atteint cette limite ? Ça arrivera le mardi 19 janvier 2038, à 03:14:07 UTC. À la seconde suivante, l'entier va déborder (overflow). Comme le compteur kilométrique d'une voiture qui passe de 999999 à 000000, le timestamp 32 bits va boucler sur sa valeur la plus négative (-2 147 483 648). Cela correspond à une date en décembre 1901.

Pour n'importe quel système 32 bits qui n'a pas été patché, cela causera un chaos chronologique. Pensez aux systèmes embarqués dans de vieilles voitures, des équipements industriels, ou des routeurs réseau.

La solution ? Utiliser un entier de 64 bits. Un entier 64 bits peut stocker un nombre si astronomiquement grand qu'il ne débordera pas avant environ 292 milliards d'années. D'ici là, le soleil aura eu le temps de s'étendre et d'avaler la Terre, donc on peut probablement considérer ça comme une solution permanente. La plupart des systèmes d'exploitation et des langages modernes ont déjà fait la transition.

Secondes intercalaires : Le grain de sable dans l'engrenage

La rotation de la Terre n'est pas parfaitement régulière ; elle ralentit légèrement. Pour garder nos horloges atomiques (qui sont, elles, super régulières) synchronisées avec le jour solaire, des organismes internationaux ajoutent occasionnellement une « seconde intercalaire » au calendrier. Cela signifie qu'une minute peut avoir 61 secondes (par ex., 23:59:60).

Alors, comment le temps Epoch gère-t-il ça ? Il ne le gère pas.

Officiellement, le standard POSIX ignore les secondes intercalaires. Il part du principe que chaque jour a exactement 86 400 secondes. Quand une seconde intercalaire se produit, les systèmes la gèrent de plusieurs façons, mais une méthode courante est de répéter la seconde précédente. Le timestamp pour 23:59:59 peut donc se produire deux fois. Cela maintient le décompte continu et ininterrompu des secondes, mais signifie qu'un timestamp Unix ne correspond pas toujours parfaitement au temps UTC réel. Pour 99,9 % des applications, ce n'est pas un problème. Pour le trading haute fréquence ou les mesures scientifiques, c'est un énorme casse-tête.

Histoires vécues

Le cas du cache qui voyageait dans le temps

Une équipe de devs lançait une nouvelle feature reposant sur un système de cache. Pour améliorer les performances, ils mettaient les données en cache pour une heure. La logique était simple : temps_expiration = temps_actuel() + 3600. Ils ont déployé le code sur toute leur flotte de serveurs.

Soudain, des bugs bizarres ont commencé à pleuvoir. Les données disparaissaient du cache presque instantanément. Après des heures de débogage frénétique, ils ont trouvé le coupable. L'un des nouveaux serveurs de la flotte avait son horloge système mal réglée — elle tournait avec cinq minutes de retard sur tous les autres serveurs.

Quand la requête d'un utilisateur arrivait sur un serveur correct, il mettait les données en cache avec un temps d'expiration de, disons, 1678886400 (12h00). Si une requête suivante pour la même donnée arrivait sur le serveur « lent », son horloge indiquait 11h55. En vérifiant le cache, il voyait un temps d'expiration à 12h00 et servait correctement la donnée. Mais si la première requête touchait le serveur lent, il fixait une expiration à 1678882800 (11h00, sa propre heure, plus une heure ce qui donne 12h00). Mais il était 11h55. Attendez, ça ne colle pas.

Reprenons. L'heure du serveur A est 12h00. Il définit une expiration de cache pour 12h00 + 1 heure = 13h00. L'horloge du serveur B est lente ; il pense qu'il est 11h55. Quand le serveur B doit écrire dans le cache, il définit une expiration à 11h55 + 1 heure = 12h55. Maintenant, si le serveur A voit un élément qui expire à 12h55, il pensera qu'il lui reste 55 minutes, tandis que le serveur B pensera qu'il a une heure complète. Cela mène à des incohérences.

Le vrai chaos commence quand les horloges sont vraiment désynchronisées. Si l'horloge du serveur B avait une heure de retard (pense qu'il est 11h00 alors qu'il est 12h00), il fixerait une expiration à 11h00 + 1 heure = 12h00. Du point de vue du serveur A, ce nouvel élément de cache expire à la seconde même où il a été créé. La donnée s'est volatilisée, en somme.

Leçon : Les timestamps Unix sont absolus, mais ils sont générés à partir d'horloges système qui peuvent ne pas l'être. Dans les systèmes distribués, garder les horloges synchronisées (généralement avec le protocole NTP, Network Time Protocol) n'est pas juste une bonne pratique ; c'est critique.

L'API qui parlait en millisecondes

Un développeur frontend construisait un dashboard pour afficher l'activité des utilisateurs. L'API backend fournissait un champ last_login avec un timestamp, du genre 1678886400. Le développeur a utilisé une librairie JavaScript pour l'afficher : new Date(1678886400).

Le résultat était bizarre. La dernière connexion de chaque utilisateur était affichée comme « 20 janvier 1970 ». Que se passait-il ?

Le développeur a passé une heure à blâmer la librairie, son code, et les phases de la lune. Finalement, il a essayé d'intégrer un autre endpoint de la même API. Cette fois, le timestamp était 1678886400123. Il avait 13 chiffres ! D'un coup, il a compris. Le constructeur de l'objet Date en JavaScript attend un timestamp en millisecondes, pas en secondes.

Le backend envoyait un timestamp standard à 10 chiffres basé sur les secondes. Le frontend interprétait 1 678 886 400 comme le nombre de millisecondes depuis l'epoch, ce qui correspond à une date quelques semaines seulement après le début de l'epoch en 1970. Le correctif était simple : new Date(1678886400 * 1000).

Leçon : Toujours, toujours, toujours vérifier la précision d'un timestamp. Une différence de trois zéros, c'est la différence entre aujourd'hui et 1970.

Erreurs et pièges courants

  • Oublier le fuseau horaire. Les timestamps Unix sont toujours, sans exception, en UTC. Quand vous en convertissez un en date lisible par un humain, votre langage de programmation ou votre outil utilisera presque toujours le fuseau horaire local de votre ordinateur. Cela peut causer une confusion monstre si vous n'en tenez pas compte. 1728409200 est un moment précis dans le temps, mais il s'affichera 06:00 à New York et 19:00 à Tokyo. Le nombre est la vérité ; l'affichage est une interprétation.

  • Mélanger les secondes et les millisecondes. C'est l'erreur classique du facteur 1000. C'est le bug le plus courant quand on travaille avec des timestamps. En règle générale : 10 chiffres, ce sont des secondes ; 13 chiffres, des millisecondes. Si vous voyez autre chose, soyez très méfiant.

  • Ignorer le problème de l'an 2038. Si vous développez une application web standard dans un langage moderne, vous êtes probablement tranquille. Mais si vous écrivez du code C pour un appareil IoT embarqué, un système d'infotainment de voiture, ou si vous maintenez un vieux système 32 bits, le bug de l'an 2038 est une véritable bombe à retardement.

  • Utiliser des chaînes de caractères ambiguës pour générer des timestamps. Créer un timestamp à partir d'une chaîne comme « 15 mars 2025 22h00 » c'est chercher les ennuis. Est-ce dans votre fuseau horaire local ? Celui du serveur ? En UTC ? Générez toujours les timestamps à partir d'objets qui gèrent les fuseaux horaires ou utilisez des chaînes UTC explicites (comme le format ISO 8601 : 2025-03-15T22:00:00Z).

Pourquoi ça doit être sur votre radar

Vous ne pouvez tout simplement pas être un développeur moderne sans comprendre le temps Epoch. C'est la lingua franca du temps en informatique. Vous le rencontrerez partout :

  • APIs : Les payloads JSON l'utilisent constamment pour des champs comme createdAt, updatedAt, et expires_at.
  • JWTs : Les claims exp (expiration), iat (issued at), et nbf (not before) sont tous des timestamps Unix standards.
  • Bases de données : Stocker le temps sous forme d'un simple entier est souvent plus efficace pour l'indexation et le stockage que d'utiliser un type complexe comme DATETIME.
  • Fichiers de log : Utiliser des timestamps numériques rend triviale la corrélation d'événements entre des dizaines de serveurs et de services différents, même s'ils sont dans des fuseaux horaires différents.
  • Systèmes de fichiers : La plupart des systèmes de fichiers stockent les dates de création et de modification des fichiers sous forme de timestamps Unix.

Comprendre son fonctionnement vous permet de déboguer toute une classe de bugs temporels complexes avec confiance. Ça vous permet de vous affranchir du monde humain désordonné des fuseaux horaires et des calendriers pour penser au temps comme un ordinateur : une simple ligne de nombres bien ordonnée.

Pour aller plus loin

Théorie bouclée. Place à la pratique — 100 % dans ton navigateur.

Essayer l'outil: Convertisseur d'époque