Qu’est-ce que l’heure d’époque Unix ? Guide du développeur sur les horodatages

Si vous avez déjà interrogé une base de données ou travaillé avec une API moderne, vous avez probablement vu des dates renvoyées non pas sous la forme "12 octobre 2026", mais sous la forme d'une chaîne de chiffres massive et intimidante comme 1791800000. Il s'agit d'un horodatage Unix, et c'est l'épine dorsale universelle de la chronométrage en informatique.

La gestion des dates et des heures dans la programmation est notoirement difficile. Les fuseaux horaires changent, l’heure d’été commence et s’arrête de manière imprévisible et les années bissextiles introduisent des jours supplémentaires. Pour résoudre cette réalité chaotique, les ingénieurs qui ont construit le système d’exploitation Unix ont décidé d’inventer leur propre chronologie absolue.

L'origine : 1er janvier 1970

Un horodatage Unix est simplement le nombre de secondes écoulées depuis le 1er janvier 1970 à 00:00:00 UTC. Ce moment précis de l’histoire est connu sous le nom de « l’époque Unix ».

Pourquoi 1970 ? Car au début des années 1970, le stockage coûtait incroyablement cher. Le stockage d'une date sous forme de chaîne lisible par l'homme, telle que "1970-01-01 00:00:00", occupe près de 20 octets de mémoire. Le stocker sous la forme d'un seul entier de 32 bits ne prenait que 4 octets. En plaçant le point de départ à proximité du moment où Unix a été inventé, ils ont maximisé la quantité de temps futur qu'ils pouvaient stocker dans ces 4 octets.

Pourquoi les développeurs aiment les horodatages Unix

La principale raison pour laquelle l'heure Unix est universellement adoptée dans les API, les bases de données et les microservices est qu'elle n'a pas de fuseau horaire. Il représente un moment unique et absolu dans le monde.

Si vous enregistrez un événement dans une base de données en utilisant l'heure du serveur local ("03h00 EST"), et que vous migrez ensuite votre serveur vers Londres, tous vos calculs échouent. Mais si un événement se produit à l'horodatage 1700000000, ce numéro est identique que l'utilisateur qui l'interroge se trouve à Tokyo, New York ou Paris. L'application frontale prend simplement cet entier et le convertit mathématiquement dans le fuseau horaire local de l'utilisateur sur son écran.

Secondes contre millisecondes (la règle des 10 contre 13 chiffres)

L'un des bugs les plus courants dans le développement Web consiste à transmettre un horodatage à une fonction et à obtenir une date en 1970 ou en 52 000. Cela se produit à cause d’une confusion entre les secondes et les millisecondes.

• Heure Unix standard (secondes) : un nombre à 10 chiffres (par exemple, 1700000000). Il s'agit de la norme sous Linux, PHP et la plupart des bases de données back-end comme MySQL.
• Durée JavaScript (millisecondes) : un nombre à 13 chiffres (par exemple, 1700000000000). La fonction Date.now() de JavaScript inclut les millisecondes pour une plus grande précision.

Si vous introduisez un horodatage backend à 10 chiffres dans JavaScript sans le multiplier par 1 000, JavaScript suppose que vous parlez des premiers jours de janvier 1970.

// Correctly handling a Unix timestamp in JavaScript
const backendTimestamp = 1700000000;
const dateObject = new Date(backendTimestamp * 1000);

console.log(dateObject.toLocaleDateString()); // Converts to local user timezone

Le problème de l’an 2038 (Y2K38)

L’heure Unix a une échéance imminente. Comme il a été initialement stocké sous la forme d'un entier signé de 32 bits, le nombre maximum qu'il peut contenir est 2 147 483 647.

Le 19 janvier 2038, à 03:14:07 UTC, l'horloge Unix atteindra ce nombre maximum. Une seconde plus tard, l'entier débordera et deviendra un nombre négatif. Les systèmes existants qui n'ont pas été mis à niveau vers une architecture 64 bits croiront soudainement que nous sommes en 1901, provoquant des pannes catastrophiques des logiciels dans le monde entier.

Heureusement, presque tous les matériels, bases de données et langages de programmation modernes (comme les noyaux Linux 64 bits et les Node.js modernes) sont déjà passés au temps 64 bits, repoussant le prochain débordement des milliards d'années dans le futur.

Foire aux questions (FAQ)