Skip to content

Temps Unix et secondes intercalaires

Solution:

Le nombre de secondes par jour est fixé avec les horodatages Unix.

Le nombre de temps Unix est zéro à l’époque Unix, et augmente d’exactement 86400 par jour depuis l’époque.

Il ne peut donc pas représenter les secondes intercalaires. Le système d’exploitation ralentira l’horloge pour s’adapter à cela. Les secondes intercalaires n’existent tout simplement pas en ce qui concerne les horodatages Unix.

L’heure Unix est facile à utiliser, mais certains horodatages ne sont pas des heures réelles et certains horodatages ne sont pas des heures uniques.

C’est-à-dire qu’il existe des horodatages en double représentant deux secondes différentes dans le temps, car dans le temps Unix, la soixantième seconde pourrait devoir se répéter (car il ne peut pas y avoir de soixante et unième seconde). Théoriquement, il pourrait également s’agir de lacunes dans le futur, car la soixantième seconde n’a pas à exister, bien qu’aucune seconde intercalaire n’ait été émise jusqu’à présent.

Justification du temps unix : il est défini de manière à ce qu’il soit facile de travailler avec. L’ajout de la prise en charge des secondes intercalaires aux bibliothèques standard est très délicat. Par exemple, vous souhaitez représenter le 1er janvier 2050 dans une base de données. Personne sur terre ne sait à combien de secondes cette date est en UTC ! La date ne peut pas être stockée sous forme d’horodatage UTC, car l’IAU ne sait pas combien de secondes intercalaires nous devrons ajouter dans les prochaines décennies (elles sont aussi bonnes que aléatoires). Alors, comment un programmeur peut-il faire de l’arithmétique de date alors que la durée qui s’écoulera entre deux dates dans le futur n’est connue qu’un an ou deux avant ? L’heure Unix est simple : nous connaissons déjà l’horodatage du 1er janvier 2050 (à savoir, 80 ans * nombre de secondes dans une année). L’UTC est extrêmement difficile à utiliser toute l’année, alors que le temps Unix n’est difficile à utiliser qu’à l’instant où une seconde intercalaire se produit.

Pour ce que ça vaut, je n’ai jamais rencontré un programmeur qui soit d’accord avec les secondes intercalaires. Ils devraient clairement être abolis.

Il y a beaucoup de discussions ici et ailleurs sur les secondes intercalaires, mais ce n’est pas un problème compliqué, car cela n’a rien à voir avec UTC, ou GMT, ou UT1, ou TAI, ou toute autre norme de temps. L’heure POSIX (Unix) est, par définition, celle qui est spécifiée par la norme IEEE Std 1003.1 “POSIX”, disponible ici.

La norme est sans ambiguïté : le temps POSIX n’inclut pas les secondes intercalaires.

Le temps universel coordonné (UTC) comprend les secondes intercalaires. Cependant, dans le temps POSIX (secondes depuis l’époque), les secondes intercalaires sont ignorées (non appliquées) pour fournir une méthode simple et compatible de calcul des différences de temps. L’heure POSIX décomposée n’est donc pas nécessairement UTC, malgré son apparence.

La norme entre dans des détails significatifs indiquant sans ambiguïté que le temps POSIX n’inclut pas les secondes intercalaires, en particulier :

Il est pratiquement impossible d’exiger qu’une implémentation conforme ait une relation fixe avec une horloge officielle particulière (considérez des systèmes isolés ou des systèmes effectuant des “réexécutions” en réglant l’horloge à une heure arbitraire).

Étant donné que les secondes intercalaires sont décidées par le comité, ce n’est pas seulement une “mauvaise idée” d’inclure les secondes intercalaires dans le temps POSIX, c’est impossible étant donné que la norme permet des implémentations conformes qui n’ont pas d’accès au réseau.

Ailleurs dans cette question, @Pacerier a déclaré que l’heure POSIX inclut les secondes intercalaires et que chaque heure POSIX peut correspondre à plusieurs heures UTC. Bien qu’il s’agisse certainement d’une interprétation possible d’un horodatage POSIX, ce n’est en aucun cas spécifié par la norme. Ses arguments se résument en grande partie à des mots de fouine qui ne s’appliquent pas à la norme, qui définit le temps POSIX.

Maintenant, les choses se compliquent. Comme spécifié par la norme, l’heure POSIX peut ne pas être équivalente à l’heure UTC :

L’heure POSIX décomposée n’est donc pas nécessairement UTC, malgré son apparence.

Cependant, dans la pratique, c’est le cas. Pour comprendre le problème, vous devez comprendre les normes de temps. GMT et UT1 sont basés sur la position astronomique de la Terre dans l’univers. Le TAI est basé sur le temps réel qui s’écoule dans l’univers tel que mesuré par des réactions physiques (atomiques). Dans TAI, chaque seconde est une “seconde SI”, qui sont toutes exactement de la même longueur. En UTC, chaque seconde est une seconde SI, mais des secondes intercalaires sont ajoutées si nécessaire pour réajuster l’horloge à moins de 0,9 seconde de GMT/UT1. Les normes horaires GMT et UT1 sont Défini par mesures empiriques de la position et du mouvement de la Terre dans l’univers, et ces mesures empiriques ne peuvent par aucun moyen (ni théorie scientifique ni approximation) être prédites. En tant que telles, les secondes intercalaires sont également imprévisibles.

Maintenant, la norme POSIX spécifie également que l’intention est que tous les horodatages POSIX soient interopérables (signifient la même chose) dans différentes implémentations. Une solution consiste à ce que tout le monde s’accorde sur le fait que chaque seconde POSIX est une seconde SI, auquel cas l’heure POSIX est équivalente à TAI (avec l’époque spécifiée), et personne n’a besoin de contacter qui que ce soit à l’exception de son horloge atomique. Nous ne l’avons pas fait, cependant, probablement parce que nous voulions que les horodatages POSIX soient des horodatages UTC.

En utilisant une faille apparente dans la norme POSIX, les implémentations ralentissent ou accélèrent intentionnellement les secondes – de sorte que l’heure POSIX n’utilise plus les secondes SI – afin de rester synchronisées avec l’heure UTC. A la lecture de la norme, il est clair que ce n’était pas ce qui était prévu, car cela ne peut pas être fait avec des systèmes isolés, qui ne peuvent donc pas interagir avec d’autres machines (leurs horodatages, sans secondes intercalaires, signifient quelque chose de différent pour les autres machines, avec secondes intercalaires). Lire:

[…] il est important que l’interprétation des noms de temps et des secondes depuis les valeurs d’époque soit cohérente dans tous les systèmes conformes ; c’est-à-dire qu’il est important que tous les systèmes conformes interprètent “536457599 secondes depuis l’époque” comme 59 secondes, 59 minutes, 23 heures le 31 décembre 1986, quelle que soit la précision de l’idée du système de l’heure actuelle. L’expression est donnée pour assurer une interprétation cohérente, et non pour tenter de spécifier le calendrier. […] Cette seconde non spécifiée est nominalement égale à une seconde du système international (SI) en durée.

La « faille » permettant ce comportement :

Notez qu’en conséquence pratique de cela, la longueur d’une seconde telle que mesurée par une norme externe n’est pas spécifiée.

Ainsi, les implémentations abusent de cette liberté en la changeant intentionnellement en quelque chose qui, par définition, ne peut pas être interopérable entre des systèmes isolés ou non participants. Alternativement, l’implémentation peut simplement répéter POSIX fois comme si aucun temps ne s’était écoulé. Voir cette réponse Unix StackExchange pour plus de détails sur toutes les implémentations modernes.

Ouf, c’était déroutant d’accord… Un vrai casse-tête !



Articles Similaires

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.