Deux couches d’encodage composent le temps Unix. La première couche encode un point dans le temps comme un nombre réel scalaire qui représente le nombre de secondes qui se sont écoulées depuis 00:00:00 UTC jeudi, 1er janvier 1970. La deuxième couche encode ce nombre sous la forme d’une séquence de bits ou de chiffres décimaux.
Comme c’est la norme avec UTC, cet article étiquette les jours en utilisant le calendrier grégorien, et compte les temps dans chaque jour en heures, minutes et secondes. Certains des exemples montrent également le temps atomique international (TAI), un autre schéma horaire qui utilise les mêmes secondes et est affiché dans le même format que l’UTC, mais dans lequel chaque jour dure exactement 86400 secondes, perdant progressivement la synchronisation avec la rotation de la Terre à un rythme d’environ une seconde par an.
Codage du temps comme un nombreEdit
Le temps Unix est un nombre signé unique qui s’incrémente chaque seconde, ce qui le rend plus facile à stocker et à manipuler pour les ordinateurs que les systèmes de date conventionnels. Les programmes d’interprétation peuvent ensuite le convertir dans un format lisible par l’homme.
L’époque Unix est le temps 00:00:00 UTC du 1er janvier 1970. Il y a un problème avec cette définition, dans la mesure où l’UTC n’existait pas sous sa forme actuelle avant 1972 ; ce problème est discuté ci-dessous. Par souci de concision, le reste de cette section utilise le format de date et d’heure ISO 8601, dans lequel l’époque Unix est 1970-01-01T00:00:00Z.
Le nombre de temps Unix est égal à zéro à l’époque Unix, et augmente d’exactement 86400 par jour depuis l’époque. Ainsi 2004-09-16T00:00:00Z, 12677 jours après l’époque, est représenté par le nombre de temps Unix 12677 × 86400 = 1095292800. On peut également revenir en arrière à partir de l’époque, en utilisant des nombres négatifs. Ainsi, 1957-10-04T00:00:00Z, 4472 jours avant l’époque, est représenté par le nombre de temps Unix -4472 × 86400 = -386380800. Cela s’applique également à l’intérieur des jours ; le nombre de temps à n’importe quel moment d’un jour est le nombre de secondes qui se sont écoulées depuis le minuit commençant ce jour ajouté au nombre de temps de ce minuit.
Parce que le temps Unix est basé sur une époque, et en raison d’un malentendu commun selon lequel l’époque Unix est la seule époque (souvent appelée « l’époque » ), le temps Unix est parfois appelé temps d’époque.
Secondes intercalairesEdit
Le schéma ci-dessus signifie que sur un jour UTC normal, qui a une durée de 86400 secondes, le numéro de temps Unix change de manière continue à travers minuit. Par exemple, à la fin de la journée utilisée dans les exemples ci-dessus, les représentations du temps progressent comme suit :
Lorsqu’une seconde intercalaire se produit, le jour UTC ne dure pas exactement 86400 secondes et le nombre de temps Unix (qui augmente toujours d’exactement 86400 chaque jour) connaît une discontinuité. Les secondes intercalaires peuvent être positives ou négatives. Aucune seconde intercalaire négative n’a jamais été déclarée, mais si c’était le cas, à la fin d’un jour avec une seconde intercalaire négative, le nombre d’heures Unix augmenterait de 1 au début du jour suivant. Lors d’une seconde intercalaire positive à la fin d’une journée, ce qui se produit environ tous les ans et demi en moyenne, le nombre d’heures Unix augmente continuellement jusqu’au jour suivant pendant la seconde intercalaire, puis à la fin de la seconde intercalaire, il remonte de 1 (pour revenir au début du jour suivant). Par exemple, voici ce qui s’est passé sur les systèmes POSIX.1 strictement conformes à la fin de 1998:
Les numéros de temps Unix sont répétés dans la seconde qui suit immédiatement une seconde intercalaire positive. Le numéro de temps Unix 1483142400 est donc ambigu : il peut faire référence soit au début de la seconde intercalaire (2016-12-31 23:59:60), soit à la fin de celle-ci, une seconde plus tard (2017-01-01 00:00:00). Dans le cas théorique où une seconde intercalaire négative se produit, aucune ambiguïté n’est causée, mais au lieu de cela, il y a une gamme de numéros de temps Unix qui ne se réfèrent à aucun point dans le temps UTC du tout.
Une horloge Unix est souvent mise en œuvre avec un type différent de gestion des secondes intercalaires positives associées au Network Time Protocol (NTP). Cela donne un système qui n’est pas conforme à la norme POSIX. Voir la section ci-dessous concernant NTP pour plus de détails.
Lorsqu’on traite des périodes qui n’englobent pas une seconde intercalaire UTC, la différence entre deux nombres de temps Unix est égale à la durée en secondes de la période entre les points de temps correspondants. Il s’agit d’une technique de calcul courante. Cependant, en cas de secondes intercalaires, ces calculs donnent une réponse erronée. Dans les applications où ce niveau de précision est requis, il est nécessaire de consulter une table des secondes intercalaires lorsqu’on traite des temps Unix, et il est souvent préférable d’utiliser un autre codage de temps qui ne souffre pas de ce problème.
Un nombre de temps Unix est facilement reconverti en temps UTC en prenant le quotient et le module du nombre de temps Unix, modulo 86400. Le quotient est le nombre de jours depuis l’époque, et le module est le nombre de secondes depuis minuit UTC ce jour-là. Si un numéro de temps Unix est ambigu en raison d’une seconde intercalaire positive, cet algorithme l’interprète comme le temps juste après minuit. Il ne génère jamais un temps qui se trouve pendant une seconde intercalaire. Si un numéro de temps Unix est invalide en raison d’une seconde intercalaire négative, il génère un temps UTC tout aussi invalide. Si ces conditions sont importantes, il est nécessaire de consulter une table des secondes intercalaires pour les détecter.
Variante non synchrone basée sur le Network Time ProtocolEdit
Communément, une horloge Unix de style Mills est implémentée avec une gestion des secondes intercalaires non synchrone avec le changement du numéro de temps Unix. Le numéro de temps diminue initialement là où un saut aurait dû avoir lieu, puis il saute à l’heure correcte 1 seconde après le saut. Cela facilite l’implémentation et est décrit dans l’article de Mills. Voici ce qui se passe à travers une seconde intercalaire positive:
Ceci peut être décodé correctement en prêtant attention à la variable d’état de la seconde intercalaire, qui indique sans ambiguïté si le saut a déjà été effectué. Le changement de variable d’état est synchrone avec le saut.
Une situation similaire se présente avec une seconde intercalaire négative, où la seconde qui est sautée est légèrement trop tardive. Très brièvement, le système affiche un nombre de temps nominalement impossible, mais cela peut être détecté par l’état TIME_DEL et corrigé.
Dans ce type de système, le nombre de temps Unix viole POSIX autour des deux types de seconde intercalaire. La collecte de la variable d’état de la seconde intercalaire avec le numéro de temps permet un décodage sans ambiguïté, de sorte que le numéro de temps POSIX correct peut être généré si désiré, ou le temps UTC complet peut être stocké dans un format plus approprié.
La logique de décodage requise pour faire face à ce style d’horloge Unix décoderait aussi correctement une horloge hypothétique conforme à POSIX utilisant la même interface. Cela serait réalisé en indiquant l’état TIME_INS pendant la totalité d’une seconde intercalaire insérée, puis en indiquant TIME_WAIT pendant la totalité de la seconde suivante tout en répétant le décompte des secondes. Cela nécessite une gestion synchrone des secondes intercalaires. C’est probablement la meilleure façon d’exprimer le temps UTC sous forme d’horloge Unix, via une interface Unix, lorsque l’horloge sous-jacente est fondamentalement non perturbée par les secondes intercalaires.
Variante basée sur le TAIEdit
Une autre variante non conforme, beaucoup plus rare, de la conservation de l’heure Unix implique l’encodage du TAI plutôt que de l’UTC ; certains systèmes Linux sont configurés de cette façon. Comme le TAI n’a pas de secondes intercalaires et que chaque jour du TAI dure exactement 86400 secondes, cet encodage est en fait un pur comptage linéaire des secondes écoulées depuis le 01/01/1970T00:00:00 TAI. Cela rend l’arithmétique des intervalles de temps beaucoup plus facile. Les valeurs temporelles issues de ces systèmes ne souffrent pas de l’ambiguïté qu’ont les systèmes POSIX strictement conformes ou les systèmes pilotés par NTP.
Dans ces systèmes, il est nécessaire de consulter une table des secondes intercalaires pour convertir correctement entre UTC et la représentation pseudo-unixienne du temps. Cela ressemble à la manière dont les tables de fuseaux horaires doivent être consultées pour convertir vers et depuis l’heure civile ; la base de données des fuseaux horaires de l’IANA comprend des informations sur les secondes intercalaires, et le code exemple disponible à partir de la même source utilise ces informations pour convertir entre les horodateurs basés sur le TAI et l’heure locale. La conversion se heurte également à des problèmes de définition avant le début en 1972 de la forme actuelle de l’UTC (voir la section Base UTC ci-dessous).
Ce système basé sur le TAI, malgré sa ressemblance superficielle, n’est pas le temps Unix. Il encode les temps avec des valeurs qui diffèrent de plusieurs secondes des valeurs de temps POSIX. Une version de ce système a été proposée pour être incluse dans le time.h d’ISO C, mais seule la partie UTC a été acceptée en 2011. Une tai_clock existe cependant en C++20.
Représentation du nombreEdit
Un nombre de temps Unix peut être représenté sous toute forme capable de représenter des nombres. Dans certaines applications, le nombre est simplement représenté textuellement comme une chaîne de chiffres décimaux, ne soulevant que des problèmes supplémentaires triviaux. Cependant, certaines représentations binaires des temps Unix sont particulièrement significatives.
Le type de données Unix time_t qui représente un point dans le temps est, sur de nombreuses plateformes, un entier signé, traditionnellement de 32 bits (mais voir ci-dessous), codant directement le nombre de temps Unix tel que décrit dans la section précédente. Le fait d’être de 32 bits signifie qu’il couvre un intervalle d’environ 136 ans au total. La date minimale représentable est le vendredi 1901-12-13, et la date maximale représentable est le mardi 2038-01-19. Une seconde après 03:14:07 UTC 2038-01-19, cette représentation débordera. Ce jalon est anticipé avec un mélange d’amusement et de crainte – voir le problème de l’année 2038.
Dans certains systèmes d’exploitation récents, time_t a été élargi à 64 bits. Cela étend les temps représentables d’environ 293 milliards d’années dans les deux sens, ce qui représente plus de vingt fois l’âge actuel de l’univers par direction.
À l’origine, il y avait une certaine controverse sur le fait que le time_t d’Unix devait être signé ou non signé. S’il était non signé, sa plage dans le futur serait doublée, repoussant le dépassement de 32 bits (de 68 ans). Cependant, il serait alors incapable de représenter les temps antérieurs à l’époque. Le consensus est que time_t doit être signé, et c’est la pratique habituelle. La plate-forme de développement logiciel de la version 6 du système d’exploitation QNX possède un time_t 32 bits non signé, bien que les versions plus anciennes utilisaient un type signé.
Les spécifications POSIX et Open Group Unix comprennent la bibliothèque standard C, qui inclut les types de temps et les fonctions définis dans le fichier d’en-tête <time.h>. La norme ISO C indique que time_t doit être un type arithmétique, mais n’impose aucun type ou encodage spécifique pour celui-ci. POSIX exige que time_t soit un type entier, mais n’impose pas qu’il soit signé ou non signé.
Unix n’a pas de tradition de représentation directe des nombres de temps Unix non entiers sous forme de fractions binaires. Au lieu de cela, les temps avec une précision inférieure à la seconde sont représentés en utilisant des types de données composites qui consistent en deux entiers, le premier étant un time_t (la partie intégrale du temps Unix), et le second étant la partie fractionnaire du nombre de temps en millionièmes (en struct timeval) ou en milliardièmes (en struct timespec). Ces structures fournissent un format de données à virgule fixe basé sur les décimales, qui est utile pour certaines applications, et trivial à convertir pour d’autres.
Base UTCEdit
La forme actuelle de l’UTC, avec les secondes intercalaires, n’est définie qu’à partir du 1er janvier 1972. Avant cela, depuis le 1er janvier 1961, il existait une forme plus ancienne d’UTC dans laquelle non seulement il y avait des pas de temps occasionnels, qui étaient par des nombres non entiers de secondes, mais aussi la seconde UTC était légèrement plus longue que la seconde SI, et changeait périodiquement pour se rapprocher continuellement de la rotation de la Terre. Avant 1961, il n’y avait pas d’UTC, et avant 1958, il n’y avait pas de chronométrage atomique répandu ; à ces époques, une certaine approximation de GMT (basée directement sur la rotation de la Terre) était utilisée au lieu d’une échelle de temps atomique.
La définition précise du temps Unix en tant qu’encodage de l’UTC n’est pas controversée uniquement lorsqu’elle est appliquée à la forme actuelle de l’UTC. L’époque d’Unix précédant le début de cette forme d’UTC n’affecte pas son utilisation à cette époque : le nombre de jours entre le 1er janvier 1970 (l’époque d’Unix) et le 1er janvier 1972 (le début d’UTC) n’est pas en question, et le nombre de jours est tout ce qui est significatif pour le temps Unix.
La signification des valeurs de temps Unix inférieures à +63072000 (c’est-à-dire avant le 1er janvier 1972) n’est pas précisément définie. La base de ces temps Unix est mieux comprise comme étant une approximation non spécifiée de l’UTC. Les ordinateurs de cette époque avaient rarement des horloges réglées avec suffisamment de précision pour fournir des horodatages significatifs à la seconde près. Le temps Unix n’est pas un moyen approprié pour représenter les temps antérieurs à 1972 dans les applications nécessitant une précision inférieure à la seconde ; ces applications doivent, au moins, définir quelle forme d’UT ou de GMT elles utilisent.
Dès 2009, la possibilité de mettre fin à l’utilisation des secondes intercalaires dans le temps civil est envisagée. Un moyen probable d’exécuter ce changement est de définir une nouvelle échelle de temps, appelée Temps international, qui correspond initialement à l’UTC mais qui par la suite n’a pas de secondes intercalaires, restant ainsi à un décalage constant du TAI. Si cela se produit, il est probable que le temps Unix sera défini prospectivement en fonction de cette nouvelle échelle de temps, au lieu de l’UTC. L’incertitude quant à cette éventualité ne rend pas le temps Unix prospectif moins prévisible qu’il ne l’est déjà : si l’UTC n’avait plus de secondes intercalaires, le résultat serait le même.