Le temps epoch expliqué : qu'est-ce que le timestamp Unix zéro ?

Ce que représente le timestamp Unix 0

Chaque timestamp Unix compte le temps écoulé depuis un point de référence unique : le 1er janvier 1970 à 00:00:00 UTC. Dans la définition d'origine d'Unix, l'unité est la seconde : le timestamp 0 est exactement minuit UTC le 1er janvier 1970, et le timestamp 86400 exactement 24 heures plus tard. Les systèmes modernes utilisent aussi millisecondes, microsecondes et nanosecondes, mais le point de référence est le même. Toute valeur positive représente un moment après l'epoch ; toute valeur négative, un moment avant.

Pourquoi le 1er janvier 1970 ?

La date a été choisie par les développeurs Unix de Bell Labs au début des années 1970 comme point de référence pratique, juste avant la création d'Unix lui-même. Elle devait être assez ancienne pour que les timestamps système normaux soient positifs, assez récente pour tenir dans les petits intervalles d'entiers des premiers ordinateurs, et assez simple à vérifier de tête. Une fois Unix devenu influent, les langages, systèmes d'exploitation, bases de données, formats de log et protocoles réseau ont hérité du même point de départ.

• Unix a été développé à Bell Labs à partir de 1969 — l'epoch a été fixé juste avant
• Le 1er janvier a été choisi comme limite de calendrier nette
• 1970 plutôt que 1969 car l'implémentation utilisait un compteur partant de zéro
• Tous les OS, langages et protocoles modernes ont hérité de cet epoch — il n'y a pas de standard concurrent

Timestamps négatifs : dates avant 1970

Les timestamps Unix négatifs représentent des moments avant le 1er janvier 1970 00:00:00 UTC. La plupart des systèmes 64 bits modernes les gèrent correctement, ce qui est utile pour les données historiques, les dates de naissance, les archives et l'interopérabilité avec des systèmes dont l'epoch précède celui d'Unix. Les anciennes bibliothèques et bases peuvent rejeter les valeurs négatives, donc les jeux de données historiques méritent une vérification de compatibilité explicite.

• -1 = December 31, 1969 23:59:59 UTC (one second before the epoch)
• -86400 = December 31, 1969 00:00:00 UTC (one day before the epoch)
• -2208988800 = January 1, 1900 00:00:00 UTC
• JavaScript: new Date(-86400 * 1000).toISOString() → '1969-12-31T00:00:00.000Z'

Limites pratiques du format

L'epoch Unix en lui-même n'est pas la limite ; c'est le type de stockage. Un timestamp stocké dans un entier signé 32 bits échoue bien plus tôt qu'un timestamp stocké dans un entier 64 bits, un nombre JavaScript ou un type timestamp natif de base. Pour évaluer la sûreté d'un timestamp, demandez à la fois quelle unité est utilisée et quel type numérique le stocke.

• 32-bit signed integer max: 2,147,483,647 = January 19, 2038 03:14:07 UTC (the Year 2038 problem)
• JavaScript Date max: 8,640,000,000,000,000 ms = September 13, 275760 CE
• 64-bit signed integer max: ~9.2 × 10^18 seconds = year ~292 billion
• PostgreSQL TIMESTAMPTZ max: January 1, 294276 CE

Les epochs d'autres systèmes

Unix n'est pas le seul epoch utilisé en informatique. D'autres systèmes ont défini leurs propres points de référence pour des raisons historiques ou techniques.

• Epoch GPS : 6 janvier 1980 00:00:00 UTC — utilisé par les satellites et récepteurs GPS
• Windows FILETIME : 1er janvier 1601 00:00:00 UTC — intervalles de 100 nanosecondes
• Apple Cocoa / NSDate : 1er janvier 2001 00:00:00 UTC
• Excel / Lotus 1-2-3 : 1er janvier 1900 — avec un bug d'année bissextile délibéré pour la compatibilité Lotus
• Système de fichiers FAT : 1er janvier 1980 00:00:00 heure locale

Secondes, millisecondes, microsecondes et nanosecondes epoch

Le mot timestamp n'indique pas toujours l'unité. Les secondes Unix sont courantes dans les systèmes d'exploitation et les langages backend. Les millisecondes Unix sont courantes en JavaScript et dans les API du navigateur. Microsecondes et nanosecondes apparaissent dans les bases, les systèmes de traçage et les logs haute résolution. L'unité contrôle à la fois la précision et le nombre de chiffres affichés.

• Seconds: 1700000000 — common in Python, PHP, Go, Ruby, C, and Unix command-line tools
• Milliseconds: 1700000000000 — common in JavaScript Date and many web analytics systems
• Microseconds: 1700000000000000 — common in some databases and event pipelines
• Nanoseconds: 1700000000000000000 — common in high-resolution tracing and systems languages
• Always document the unit when storing epoch values in APIs, CSV files, and database columns

Temps epoch vs UTC vs heure locale

Le temps epoch est un décompte. UTC est le standard de temps global qui définit le moment de référence. L'heure locale est un choix d'affichage basé sur un fuseau comme America/New_York ou Asia/Tokyo. Un timestamp Unix ne change pas quand un utilisateur voyage ; seuls la date de calendrier et l'heure formatées changent.

• Le même timestamp peut s'afficher comme des dates locales différentes selon le fuseau
• La sortie UTC est la meilleure pour les logs, les API et le débogage entre serveurs
• La sortie locale est la meilleure pour les calendriers, les interfaces et les rapports
• Les décalages de fuseau s'appliquent lors du formatage, pas stockés dans le timestamp Unix

FAQ sur le temps epoch

Le temps epoch est-il toujours en secondes ?

Le timestamp Unix classique est en secondes depuis 1970-01-01 00:00:00 UTC, mais beaucoup de systèmes utilisent millisecondes, microsecondes ou nanosecondes avec le même epoch.

Les timestamps Unix peuvent-ils représenter des dates avant 1970 ?

Oui. Les timestamps négatifs représentent des dates avant l'epoch Unix, bien que d'anciennes bibliothèques et bases puissent ne pas les gérer.

Un timestamp Unix inclut-il un fuseau horaire ?

Non. Un timestamp Unix représente un instant en UTC. Le fuseau n'est utilisé que pour convertir cet instant en une date locale lisible.

Quel est le timestamp Unix maximal ?

Cela dépend du type de stockage, pas de l'epoch. Un entier signé 32 bits plafonne à 2,147,483,647 (19 janvier 2038), tandis qu'un entier 64 bits ou un nombre JavaScript atteint des centaines de millions d'années. Voir le bug de l'an 2038 pour les détails.