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
The Unix epoch (1970-01-01 UTC) was inherited from Multics, the OS that influenced early Unix design. POSIX later standardized the time_t type with explicit semantics that differ from how the original Unix specs described it — and most other platforms count from a different epoch entirely.
- Multics (1969) counted seconds from 1970-01-01 GMT; Unix adopted the same epoch in 1971
- POSIX time_t is defined as a count of seconds since 1970 UTC, explicitly excluding leap seconds (every day is 86,400 ticks)
- POSIX vs Unix terminology: in practice the two are used interchangeably; POSIX is the standardized name
- Other software epochs differ widely:
- Windows FILETIME — 1601-01-01 UTC (Gregorian-cycle start), 100-nanosecond intervals
- .NET DateTime.Ticks — 0001-01-01, 100-nanosecond intervals
- Apple / Core Data — 2001-01-01 UTC (Cocoa reference date), seconds
- NTP — 1900-01-01 UTC, seconds; GPS — 1980-01-06, seconds (no leap seconds)
- Julian Day — noon UT, 4713 BC (proleptic Julian), days
- When importing time data, confirm the epoch before trusting the value as Unix time
Related articles
FAQ
- Is epoch time always in seconds?
- The classic Unix timestamp is seconds since 1970-01-01 00:00:00 UTC, but many systems use milliseconds, microseconds, or nanoseconds with the same epoch.
- Can Unix timestamps represent dates before 1970?
- Yes. Negative timestamps represent dates before the Unix epoch, though older libraries and databases may not support them.
- Does a Unix timestamp include a timezone?
- No. A Unix timestamp represents one instant in UTC. Timezone information is used only when converting that instant into a readable local date.
- What is the maximum Unix timestamp?
- It depends on the storage type, not the epoch. A 32-bit signed integer maxes out at 2,147,483,647 (January 19, 2038), while a 64-bit integer or a JavaScript number reaches hundreds of millions of years. See the Year 2038 problem for the details.