Le temps Unix est la plomberie sous presque tous les horodatages que vous toucherez : created_at en base, expiration d'un JWT, heure d'une ligne de log, date de modification d'un fichier, en-têtes HTTP. Malgré son omniprésence, il a des bizarreries qui surprennent les développeurs chaque année — secondes vs millisecondes, pièges de fuseau horaire, dépassement de 2038 qui approche. Ce guide couvre ce qu'il est vraiment et comment le manipuler sans se couper.

Ce que c'est

Le temps Unix est le décompte des secondes écoulées depuis 00:00:00 UTC le 1er janvier 1970, l'epoch Unix. Chaque instant devient un entier unique — une droite numérique ancrée en 1970 qui s'étend vers le futur (positif) et, moins utile, vers le passé (négatif). Aujourd'hui, le temps Unix tourne autour de 1,78 milliard et grimpe.

Pourquoi 1970

Unix était en développement aux Bell Labs quand l'équipe eut besoin d'un point zéro pour ses fonctions de temps. Les candidats évidents — une année historiquement significative, un siècle rond — traînaient des bagages. Le choix pragmatique : une date récente et ronde, le 1er janvier 1970 à 00:00:00 UTC. Rien de particulier n'arriva ce jour-là. Sa valeur était d'être assez proche d'aujourd'hui pour garder les nombres petits, et assez loin dans le passé pour que les fichiers existants n'aient pas besoin d'horodatages négatifs.

Secondes ou millisecondes

Le temps Unix originel est en secondes. Tout système POSIX — Linux, macOS, bases de données, time.time() Python casté en int — renvoie des secondes. Mais JavaScript a choisi les millisecondes pour Date.now() spécifié en 1995, et la plupart des API modernes (Java, stdlib Go, formats ISO, bases modernes) ont suivi. Résultat : deux conventions coexistent. Un horodatage à 10 chiffres est presque toujours en secondes ; un à 13 chiffres en millisecondes. En construisant une intégration, vérifiez de quel côté est l'autre système — mélanger est silencieux et produit des dates à 53 ans d'écart.

Fuseaux horaires et ce que le temps Unix représente vraiment

Le temps Unix est toujours UTC. Il ne connaît pas les fuseaux. Quand un log dit « créé 1712345678 », c'est un point exact dans le temps global — le convertir en chaîne lisible, c'est là qu'entre le fuseau horaire. C'est en réalité une vertu : serveurs, utilisateurs et bases peuvent rendre le même instant dans leur heure locale sans jamais être en désaccord sur le quand.

Le problème Y2038

Le 19 janvier 2038 à 03:14:07 UTC, un entier signé 32 bits contenant des secondes Unix déborde. La seconde suivante bascule sur un nombre négatif, interprété comme le 13 décembre 1901. Tout système qui stocke encore le temps Unix en int32 verra les dates s'emmêler. Appareils embarqués, anciens formats binaires, programmes C longévifs sont les risques principaux — votre application web va presque certainement bien, car tout langage et base mainstream est passé en 64 bits il y a longtemps. Un horodatage Unix 64 bits ne dépasse pas avant ~292 milliards d'années.

Pourquoi il domine encore

Tout autre format d'horodatage a besoin d'un fuseau, d'un système calendaire ou d'un parser pour être sensé. Le temps Unix est un nombre unique, interprétable sans contexte, triable sans parsage, compact en stockage, peu coûteux à comparer. Ses descendants — ISO 8601 et RFC 3339 pour l'affichage, horloges monotones pour mesurer l'écoulé — couvrent ce qu'il ne couvre pas seul. Mais pour « à quel instant global cela s'est-il produit », l'epoch de 1970 a gagné et ne sera sans doute pas remplacé.