Clause de non-responsabilité:

Je viens de parcourir la liste des sites StackExchange pendant environ 20 minutes en essayant de comprendre où publier cela. Si vous connaissez un site plus adapté, veuillez y déplacer cette question. Je poste ceci ici parce que le temps Unix m'a fait réfléchir.

Donc, comme nous le savons tous, il y a un temps Unix et il y a UTC. Le temps Unix continue de tourner, en comptant les secondes - une seconde par seconde -, tandis que l'UTC essaie de garder le temps dans les formats lisibles par l'homme que nous utilisons alignés avec la phase de la Terre dans sa rotation. Pour ce faire, UTC insère de temps en temps des secondes intercalaires.

Étant donné que le temps est relatif à la force gravitationnelle à laquelle l'objet subissant le temps est exposé, à d'autres types d'accélération et à la vitesse relative, cela conduit à 2 questions. Passons d'abord au plus simple: où le temps Unix est-il mesuré? Si Alice et Bob commencent à convenir, l'heure actuelle est 1467932496.42732894722748 quand ils sont au même endroit (un second étant bien sûr défini comme 9'192'631'770 cycles de rayonnement correspondant à la transition entre deux niveaux d'énergie du césium-133 atome au repos et à 0 K), l'expérience d'un double paradoxe dû à Alice vivant au niveau de la mer et à Bob vivant en haut des montagnes ou à Alice vivant au pôle nord et à Bob vivant à l'équateur, ils ne seront plus d'accord. Alors, comment le temps Unix est-il défini précisément?

Vous ne voyez peut-être pas le problème avec l'UTC au début parce que tout le monde peut sûrement s'entendre sur le moment où la terre a terminé une orbite (cela ignore bien sûr le mouvement de la plaque continentale, mais je pense que nous comprenons assez bien car avec le GPS, il est possible de mesurer leur mouvement très précisément et nous pouvons supposer qu'ils sont sur une position fixe dans notre modèle et ne se déplacent pas lorsque les plaques continentales se déplacent), qu'ils soient sur une montagne, au niveau de la mer, sur l'équateur ou au pôle nord. Il peut y avoir des décalages horaires mais ils ne s'accumulent pas.

Mais une seconde est définie comme 9'192'631'770 cycles de rayonnement correspondant à la transition entre deux niveaux d'énergie de l'atome de césium 133 au repos et à 0 K et l'atome de césium 133 ne se soucie pas de l'orbite terrestre. L'UTC décide donc où insérer une seconde intercalaire, mais il doit y avoir un décalage mesuré ou prévu entre la phase de l'orbite terrestre et le temps mesuré quelque part par une horloge atomique. Où est-ce quelque part?

Votre question principale n'a pas de vraie réponse; Le temps Unix n'est pas une échelle de temps réelle et n'est "mesuré" nulle part. C'est une représentation de l'UTC, bien que pauvre car il y a des moments en UTC qu'elle ne peut pas représenter. Le temps Unix insiste sur le fait qu'il y a 86 400 secondes par jour, mais UTC s'écarte de cela en raison des secondes intercalaires.

En ce qui concerne votre question plus large, il existe quatre échelles de temps importantes:

1. UT1 (Universal Time), calculé par des observatoires du monde entier qui mesurent la rotation de la Terre par rapport aux étoiles fixes. Avec ces observations et un peu de calcul, nous obtenons une version plus moderne de l'ancien temps moyen de Greenwich, qui était basé sur le moment du midi solaire à l'Observatoire Royal de Greenwich. Le temps universel est calculé par une organisation appelée IERS (International Earth Rotation and Reference Systems Service, anciennement International Earth Rotation Service).

2. TAI (International Atomic Time), qui est conservé par des centaines d'horloges atomiques à travers le monde, maintenu par des organismes nationaux de normalisation et autres. Les gardiens des horloges qui contribuent au TAI utilisent des techniques de transfert de temps pour orienter leurs horloges les unes vers les autres, annulant les petites erreurs des horloges individuelles et créant un temps d'ensemble; cet ensemble est le TAI, publié par le Bureau international des poids et mesures (BIPM), les responsables du système d'unités SI. Pour répondre à votre question sur la dilatation du temps, TAI est défini comme étant le temps atomique au niveau de la mer (en fait, au géoïde, qui est une version plus sophistiquée de la même idée), et chaque horloge corrige les effets de sa propre altitude.

3. UTC (temps universel coordonné). L'UTC a été fixée à dix secondes derrière TAI le 1er janvier 1972 et, depuis cette date, elle avance exactement au même rythme que TAI, sauf lorsqu'une seconde intercalaire est ajoutée ou soustraite. L'IERS décide d'annoncer une seconde intercalaire afin de maintenir la différence à moins de 0,9 seconde (en pratique, à environ 0,6 seconde; une seconde intercalaire supplémentaire fait passer la différence de -0,6 à +0,4). En théorie, les secondes intercalaires peuvent être à la fois positives et négatives, mais comme la rotation de la Terre ralentit par rapport à la norme établie par SI et TAI, une seconde intercalaire négative n'a jamais été nécessaire et ne le sera probablement jamais.

4. Le temps Unix, qui fait de son mieux pour représenter UTC comme un numéro unique. Chaque heure Unix qui est un multiple de 86 400 correspond à minuit UTC. Étant donné que tous les jours UTC ne durent pas 86 400 secondes, mais tous les "jours Unix", il existe une différence irréconciliable qui doit être corrigée d'une manière ou d'une autre. Il n'y a pas de temps Unix correspondant à une seconde intercalaire supplémentaire. En pratique, les systèmes agiront comme si la seconde précédente s'était produite deux fois (avec l'horodatage Unix sautant en arrière d'une seconde, puis recommençant), ou appliquaient une technique telle que le maculage par saut qui déformait le temps pendant une plus longue période de chaque côté de une seconde intercalaire. Dans les deux cas, il y a une inexactitude, bien qu'au moins le second soit monotone. Dans les deux cas,et b n'est pas égal à ba; il est égal à ba plus le nombre de secondes intercalaires intermédiaires .

Étant donné que UT1, TAI, UTC et l'IERS sont tous des efforts mondiaux et multinationaux, il n'y a pas un seul "où", bien que les bulletins IERS soient publiés par l'Observatoire de Paris et que le BIPM soit également basé à Paris, c'est une réponse. Une organisation qui nécessite un temps précis et traçable peut indiquer sa base de temps comme quelque chose comme "UTC (USNO)", ce qui signifie que ses horodatages sont en UTC et qu'ils sont dérivés de l'heure de l'US Naval Observatory, mais étant donné les problèmes Je l'ai mentionné avec le temps Unix, il est fondamentalement incompatible avec ce niveau de précision - toute personne ayant un temps vraiment précis aura une alternative au temps Unix.

Les réglages de l'horloge sont coordonnés par l'IERS. Ils planifient l'insertion d'une seconde intercalaire dans le flux de temps selon les besoins.

Depuis l' échelle de temps NTP et les secondes intercalaires

Le Service international de rotation de la Terre (IERS) de l'Observatoire de Paris utilise les observations astronomiques fournies par l'USNO et d'autres observatoires pour déterminer l'échelle de temps UT1 (navigateur) corrigée des variations irrégulières de la rotation de la Terre.

À ma connaissance, 23:59:60 (seconde intercalaire) et 00:00:00 le lendemain sont considérés comme la même seconde en temps Unix.

Le temps UNIX est mesuré sur votre ordinateur exécutant UNIX.

Cette réponse va vous demander de savoir ce que sont le temps universel coordonné (UTC), le temps atomique international (TAI) et le second SI. Les expliquer dépasse largement le cadre d'Unix et Linux Stack Exchange. Ce ne sont pas les échanges de pile de physique ou d'astronomie.

Le matériel

Votre ordinateur contient divers oscillateurs qui pilotent les horloges et les minuteries. Exactement ce qu'il a varie d'un ordinateur à l'autre en fonction de son architecture. Mais généralement et en termes très généraux:

• Il y a un temporisateur d'intervalle programmable (PIT) quelque part, qui peut être programmé pour compter un nombre donné d'oscillations et déclencher une interruption de l'unité centrale de traitement.
• Il y a un compteur de cycles sur le processeur central qui compte simplement 1 pour chaque cycle d'instructions exécuté.

La théorie du fonctionnement, en termes très larges

Le noyau du système d'exploitation utilise le PIT pour générer des ticks . Il configure le PIT en mode libre, comptant le bon nombre d'oscillations pendant un intervalle de temps, disons, d'un centième de seconde, générant une interruption, puis réinitialisant automatiquement le comptage pour recommencer. Il existe des variations à ce sujet, mais essentiellement cela provoque une interruption de tick à une fréquence fixe.

Dans le logiciel, le noyau incrémente un compteur à chaque tick. Il connaît la fréquence des ticks, car il a programmé le PIT en premier lieu. Il sait donc combien de ticks composent une seconde. Il peut l'utiliser pour savoir quand incrémenter un compteur qui compte des secondes. Ce dernier est l'idée du noyau de "UNIX Time". En effet, il compte simplement à la hausse à raison d'un par seconde SI s'il est laissé à ses propres appareils.

Quatre choses compliquent cela, que je vais présenter en termes très généraux.

Le matériel n'est pas parfait. Un PIT dont la fiche technique indique qu'il a une fréquence d'oscillateur de N Hertz pourrait plutôt avoir une fréquence de (disons) N .00002 Hertz, avec les conséquences évidentes.

Ce schéma interagit très mal avec la gestion de l'alimentation, car le processeur se réveille des centaines de fois par seconde pour faire un peu plus qu'incrémenter un nombre dans une variable. Ainsi, certains systèmes d'exploitation ont ce que l'on appelle des conceptions «sans tique». Au lieu de faire en sorte que le PIT envoie une interruption pour chaque tick, le noyau calcule (à partir de l'ordonnanceur de bas niveau) combien de ticks vont se passer sans quanta de thread, et programme le PIT pour compter autant de ticks dans le avant d'émettre une interruption de tick. Il sait qu'il doit alors enregistrer le passage de N ticks à la prochaine interruption de tick, au lieu de 1 tick.

Le logiciel d'application a la capacité de changer l'heure actuelle du noyau. Il peut augmenter la valeur ou faire pivoter la valeur. L'orientation consiste à ajuster le nombre de ticks qui doivent passer pour incrémenter le compteur de secondes. Le compteur de secondes ne compte donc pas nécessairement au rythme de un par seconde SI de toute façon , même en supposant des oscillateurs parfaits. Le pas implique simplement d'écrire un nouveau nombre dans le compteur de secondes, ce qui ne se produit généralement pas avant 1 seconde SI depuis la dernière seconde.

Les noyaux modernes comptent non seulement les secondes, mais aussi les nanosecondes. Mais il est ridicule et souvent irréalisable d'avoir une interruption de tique une fois par nanoseconde. C'est là que des choses comme le compteur de cycles entrent en jeu. Le noyau se souvient de la valeur du compteur de cycles à chaque seconde (ou à chaque tick) et peut calculer, à partir de la valeur actuelle du compteur lorsque quelque chose veut connaître le temps en nanosecondes, combien de nanosecondes doivent s'être écoulées depuis la dernière seconde (ou cocher). Encore une fois, cependant, la gestion de l'alimentation et de la chaleur fait des ravages car la fréquence du cycle d'instruction peut changer, de sorte que les noyaux font des choses comme s'appuyer sur du matériel supplémentaire comme (par exemple) un temporisateur d'événements de haute précision (HPET).

Le langage C et POSIX

La bibliothèque standard de la langue C décrit le temps en termes d'un type opaque, time_tun type de structure tmavec différents domaines spécifiés, ainsi que diverses fonctions de bibliothèque comme time(), mktime()et localtime().

En bref: le langage C lui-même garantit simplement qu'il time_ts'agit d'un des types de données numériques disponibles et que le seul moyen fiable de calculer les différences de temps est la difftime()fonction. C'est le standard POSIX qui fournit les garanties les plus strictes qui time_test en fait l'un des types entiers et qu'il compte en secondes depuis l'Époque . C'est également la norme POSIX qui spécifie le timespectype de structure.

La time()fonction est parfois décrite comme un appel système. En fait, cela n'a pas été l'appel système sous-jacent sur de nombreux systèmes depuis assez longtemps, de nos jours. Sur FreeBSD, par exemple, l'appel système sous-jacent est clock_gettime(), qui dispose de différentes "horloges" qui mesurent en secondes ou en secondes + nanosecondes de différentes manières. C'est cet appel système par lequel le logiciel d'application lit l'heure UNIX à partir du noyau. (Un clock_settime()appel système correspondant leur permet de le déplacer et un adjtime()appel système leur permet de le faire pivoter.)

Beaucoup de gens agitent la norme POSIX avec des affirmations très précises et précises sur ce qu'elle prescrit. Ces personnes n'ont, le plus souvent, pas réellement lu la norme POSIX. Comme l'explique sa justification, l'idée de compter "secondes depuis l'époque", qui est la phrase que la norme utilise, ne spécifie pas intentionnellement que les secondes POSIX sont de la même longueur que les secondes SI, ni que le résultat gmtime()est "nécessairement UTC, malgré son apparence ". La norme POSIX est intentionnellementsuffisamment lâche pour qu'il permette (par exemple) un système UNIX où l'administrateur va et corrige manuellement les ajustements de la seconde intercalaire en remettant à zéro l'horloge la semaine après qu'ils se produisent. En effet, la justification souligne qu'elle est intentionnellement assez lâche pour s'adapter aux systèmes où l'horloge a été délibérément réglée à une heure autre que l'heure UTC actuelle.

UTC et TAI

L'interprétation de UNIX Time obtenue à partir du noyau dépend des routines de bibliothèque exécutées dans les applications. POSIX spécifie une identité entre le temps du noyau et un "temps décomposé" dans a struct tm. Mais, comme Daniel J. Bernstein l'a souligné une fois, l'édition 1997 de la norme s'est trompée de façon embarrassante sur cette identité, brouillant la règle de l'année bissextile du calendrier grégorien (quelque chose que les écoliers apprennent) de sorte que le calcul était erroné à partir de l'année 2100. "Plus honoré dans la brèche que l'observance" est une phrase qui me vient à l'esprit.

Et c'est effectivement le cas. De nos jours, plusieurs systèmes basent cette interprétation sur des routines de bibliothèque écrites par Arthur David Olson, qui consultent la fameuse "base de données de fuseau horaire Olson", généralement encodée dans des fichiers de base de données sous /usr/share/zoneinfo/. Le système Olson avait deux modes:

• Les "secondes depuis l'époque" du noyau sont considérées comme comptant les secondes UTC depuis le 1970-01-01 00:00:00 UTC, à l'exception des secondes intercalaires. Cela utilise l' posix/ensemble des fichiers de base de données de fuseau horaire Olson. Tous les jours ont 86400 secondes de noyau et il n'y a jamais 61 secondes dans une minute, mais elles ne sont pas toujours de la longueur d'une seconde SI et l'horloge du noyau doit pivoter ou avancer lorsque des secondes intercalaires se produisent.
• Les "secondes depuis l'époque" du noyau sont considérées comme comptant les secondes TAI depuis le 1970-01-01 00:00:10 TAI. Cela utilise l' right/ensemble des fichiers de base de données de fuseau horaire Olson. Les secondes du noyau durent 1 seconde SI et l'horloge du noyau n'a jamais besoin de pivoter ou de se déplacer pour s'adapter aux secondes intercalaires, mais les temps décomposés peuvent avoir des valeurs telles que 23:59:60 et les jours ne sont pas toujours longs de 86400 secondes.

M. Bernstein a écrit plusieurs outils, y compris son daemontoolsjeu d'outils, qui nécessitaient right/car ils ont simplement ajouté 10 time_tpour obtenir des secondes TAI depuis 1970-01-01 00:00:00 TAI. Il a documenté cela dans la page de manuel.

Cette exigence a été (peut-être inconsciemment) héritée par des ensembles d'outils tels que daemontools-encoreet runitet par Felix von Leitner.libowfat . Utilisez Bernsteinmultilog , Guentermultilog ou Papesvlogd avec une posix/configuration Olson , par exemple, et tous les horodatages TAI64N auront (au moment de la rédaction de ce document) 26 secondes de retard sur le nombre réel de secondes TAI depuis 1970-01-01 00:00:10 TAI.

Laurent Bercot et moi avons abordé cette question en s6 et nosh, bien que nous ayons adopté des approches différentes. M. Bercot tai_from_sysclock()s'appuie sur un indicateur de compilation. les outils nosh qui traitent dans TAI64N regardent les variables d'environnement TZet TZDIRpour détecter automatiquement posix/et right/si elles le peuvent.

Fait intéressant, les documents time2posix()et posix2time()fonctions FreeBSD qui permettent l'équivalent du right/mode Olson avec time_tcomme secondes TAI. Cependant, ils ne sont apparemment pas activés.

Encore une fois…

Le temps UNIX est mesuré sur votre ordinateur exécutant UNIX, par des oscillateurs contenus dans le matériel de votre ordinateur. Il n'utilise pas SI secondes; ce n'est pas UTC même s'il peut lui ressembler superficiellement; et cela permet intentionnellement à votre horloge de se tromper.

Lectures complémentaires

• Daniel J. Bernstein. Heure UTC, TAI et UNIX . cr.yp.to.
• Daniel J. Bernstein. tai64nlocal. Daemon Tools. cr.yp.to.
• " secondes depuis l'époque ". Spécification UNIX unique version 2 . 1997. The Open Group.
• " Secondes depuis l'époque (justification) ". Spécifications de base Problème 6 . 2004. IEEE 1003.1. Le groupe ouvert.
• David Madore (17/12/2010). Le désordre de seconde intercalaire Unix .
• time2posix. Manuel FreeBSD 10.3. § 3.
• /physics/45739/
• /astronomy/11840/