FAQ sur les timestamps Unix

FAQ

Qu'est-ce qu'un horodatage Unix ?

Un horodatage Unix est le nombre de secondes écoulées depuis l'epoch Unix — le 1er janvier 1970 à 00:00:00 UTC. C'est un entier neutre vis-à-vis du langage et indépendant du fuseau horaire qui identifie de façon unique n'importe quel instant.

Qu'est-ce que l'epoch Unix ?

L'epoch Unix est le 1er janvier 1970 à 00:00:00 UTC. Tous les horodatages Unix se mesurent vers l'avant — ou vers l'arrière pour les valeurs négatives — à partir de ce point de référence fixe. Le choix de 1970 était pratique : c'était une année récente et ronde au moment de la conception d'Unix aux Bell Labs.

Quelle est la différence entre un horodatage à 10 chiffres et un à 13 chiffres ?

Un horodatage à 10 chiffres (p. ex. 1700000000) représente des secondes depuis l'epoch. Un à 13 chiffres (p. ex. 1700000000000) représente des millisecondes. Le Date.now() de JavaScript renvoie des millisecondes ; la plupart des appels système Unix et des langages comme Python, Go et PHP renvoient des secondes par défaut.

Pourquoi JavaScript utilise-t-il des millisecondes plutôt que des secondes ?

L'API Date de JavaScript a été conçue pour correspondre à la résolution des minuteries système disponibles en 1995. Utiliser des millisecondes évite la perte de précision pour les durées inférieures à la seconde. Quand vous manipulez des horodatages Unix en secondes générés par le serveur, multipliez par 1000 avant de les passer à new Date().

Comment convertir un horodatage Unix en date lisible en JavaScript ?

Pour un horodatage en secondes : new Date(1700000000 * 1000).toISOString(). Pour un horodatage en millisecondes : new Date(1700000000000).toISOString(). Les deux produisent des chaînes ISO 8601 comme '2023-11-15T06:13:20.000Z'. Utilisez toLocaleString() avec une option timeZone pour un affichage localisé.

Les horodatages Unix tiennent-ils compte du fuseau horaire ?

Non. Un horodatage Unix représente toujours un instant unique en UTC. L'information de fuseau n'est appliquée que lors du formatage de l'horodatage pour l'affichage. Deux appareils dans des fuseaux différents produiront le même horodatage Unix pour le même instant.

Qu'est-ce que le problème de l'an 2038 ?

Les systèmes qui stockent les horodatages Unix sous forme d'entiers signés 32 bits ne peuvent représenter que des valeurs jusqu'à 2 147 483 647, ce qui correspond au 19 janvier 2038 à 03:14:07 UTC. Après cet instant, l'entier déborde vers un grand nombre négatif. Les systèmes 64 bits modernes ne sont pas concernés, mais les systèmes embarqués et les bases de données héritées peuvent rester à risque.

Qu'est-ce qu'un horodatage Unix négatif ?

Un horodatage Unix négatif représente un instant antérieur à l'epoch Unix. Par exemple, -86400 correspond au 31 décembre 1969 à 00:00:00 UTC. La plupart des API de date modernes gèrent correctement les horodatages négatifs, mais certains systèmes et bases de données plus anciens ne les prennent pas en charge.

Comment obtenir un horodatage Unix en Python ?

Utilisez import time; int(time.time()) pour les secondes. Pour un datetime UTC explicite : import datetime; int(datetime.datetime.now(datetime.timezone.utc).timestamp()). Pour les millisecondes : int(time.time() * 1000).

Quelle est la précision d'un horodatage Unix ?

Un horodatage Unix standard a une précision d'une seconde. Pour une précision inférieure à la seconde, les horodatages en millisecondes (13 chiffres) sont courants dans les API web et JavaScript. Certains systèmes utilisent des microsecondes (16 chiffres) ou des nanosecondes. L'unité appropriée dépend de la précision dont votre application a réellement besoin.

Quelle taille peut atteindre un horodatage Unix ?

Sur un entier signé 64 bits (le standard actuel), les horodatages Unix peuvent représenter n'importe quel instant d'environ 292 milliards d'années dans le passé à 292 milliards d'années dans le futur. La fameuse limite 32 bits (le problème de l'an 2038) ne s'applique qu'aux systèmes hérités.

Pourquoi mon horodatage affiche-t-il 1970 ?

Généralement pour l'une de trois raisons : la valeur est 0 (l'epoch lui-même), la valeur est en millisecondes mais a été traitée comme des secondes (elle s'arrondit donc à une valeur de secondes minuscule proche de 0), ou la valeur est null/undefined et votre code l'a fixée par défaut à 0.

Quelle est la différence entre UTC et GMT ?

Pour la plupart des usages, UTC et GMT sont interchangeables. L'UTC (Temps universel coordonné) est le standard atomique moderne ; le GMT (Greenwich Mean Time) est un terme hérité pour le fuseau à décalage zéro. Le Royaume-Uni et la plupart des logiciels les traitent comme équivalents.

Dois-je stocker les dates en horodatages Unix ou en chaînes ISO 8601 ?

Les deux fonctionnent. Les entiers Unix sont compacts et triviaux à comparer ; les chaînes ISO 8601 sont auto-descriptives et lisibles par l'humain. En base de données, les types datetime natifs (TIMESTAMP WITH TIME ZONE dans Postgres, DATETIME(6) dans MySQL) sont généralement les meilleurs car ils préservent la sémantique de fuseau et s'indexent efficacement.

Est-il sûr de stocker l'heure locale de mon serveur ?

Non. Stocker l'heure locale sans décalage perd de l'information dès que le serveur change de lieu, que l'heure d'été change ou qu'un autre serveur dans un autre fuseau lit la valeur. Stockez l'UTC (en horodatage Unix ou en datetime conscient du fuseau) et ne convertissez en heure locale qu'à la couche d'affichage.

Les horodatages Unix incluent-ils les secondes intercalaires ?

Le temps Unix POSIX ignore délibérément les secondes intercalaires — chaque jour Unix fait exactement 86 400 secondes même quand une seconde UTC supplémentaire est insérée. Le numéro de seconde réel est répété ou l'horloge est lissée, selon le système.