Temps Unix et secondes intercalaires
Concernant l'heure Unix (POSIX), Wikipedia dit:
En raison de sa gestion des secondes intercalaires, il ne s'agit ni d'une représentation linéaire du temps ni d'une véritable représentation de l'UTC.
Mais la commande Unix date ne semble pas en être consciente
$ date -d '@867715199' --utc
Mon Jun 30 23:59:59 UTC 1997
$ date -d '@867715200' --utc
Tue Jul 1 00:00:00 UTC 1997
Alors qu'il devrait y avoir une seconde intercalaire à Mon Jun 30 23:59:60 UTC 1997.
Est-ce à dire que seule la commande date ignore les secondes intercalaires, contrairement au concept du temps Unix?
Le nombre de secondes par jour est fixe avec horodatages Unix .
Le nombre de temps Unix est nul à l'époque Unix, et augmente exactement de 86400 par jour depuis l'époque.
Il ne peut donc pas représenter des 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.
Le temps Unix est facile à utiliser, mais certains horodatages ne sont pas des temps réels et certains horodatages ne sont pas des temps uniques.
Autrement dit, il existe des horodatages en double représentant deux secondes différentes dans le temps, car en temps Unix, la soixantième seconde pourrait devoir se répéter (car il ne peut pas y avoir une soixante et unième seconde). Théoriquement, ils pourraient également être des lacunes à l'avenir car la soixantième seconde n'a pas à exister, bien qu'aucune seconde intercalaire à sauter n'ait été émise jusqu'à présent.
Justification du temps Unix: il est défini de sorte qu'il est 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 la forme d'un horodatage UTC, car l'IAU ne sait pas combien de secondes intercalaires nous devrons ajouter au cours des prochaines décennies (elles sont aussi aléatoires). Alors, comment un programmeur peut-il faire l'arithmétique des dates alors que la durée qui s'écoulera entre deux dates à l'avenir n'est connue qu'un an ou deux auparavant? L'heure Unix est simple: nous connaissons déjà l'horodatage du 1er janvier 2050 (à savoir 80 ans * # de secondes dans une année). L'UTC est extrêmement difficile à travailler toute l'année, alors que le temps Unix n'est difficile à travailler qu'à l'instant où une seconde se produit.
Pour ce que ça vaut, je n'ai jamais rencontré de 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, en 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 rentre dans les moindres détails en précisant sans ambiguïté que le temps POSIX n'inclut pas les secondes intercalaires, en particulier:
Il est pratiquement impossible d'imposer qu'une implémentation conforme ait une relation fixe avec une horloge officielle particulière (envisagez des systèmes isolés ou des systèmes effectuant des "réexécutions" en réglant l'horloge sur une heure arbitraire).
Puisque les secondes intercalaires sont décidées par le comité, ce n'est pas seulement une "mauvaise idée" d'inclure des secondes intercalaires dans le temps POSIX, il est impossible étant donné que la norme permet des implémentations conformes qui n'ont pas 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 à plus d'une heure UTC. Bien que ce soit certainement une interprétation possible d'un horodatage POSIX, ce n'est en aucun cas spécifié par la norme. Ses arguments reviennent en grande partie à des mots de belette 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, en pratique, c'est le cas. Afin de 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. TAI est basé sur la quantité réelle de temps qui passe dans l'univers mesurée par des réactions physiques (atomiques). Dans TAI, chaque seconde est une "seconde SI", qui ont toutes exactement 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 étalons de temps GMT et UT1 sont définis par des mesures empiriques de la position et du mouvement de la Terre dans l'univers, et ces mesures empiriques ne peuvent en aucun cas (ni théorie scientifique ni approximation). En tant que tel, 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 convienne que chaque seconde POSIX est une seconde SI, auquel cas le temps POSIX est équivalent à TAI (avec l'époque spécifiée), et personne n'a besoin de contacter qui que ce soit, sauf pour 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. En lisant 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 d'autres machines, avec des secondes intercalaires). Lis:
[...] il est important que l'interprétation des noms de temps et des secondes puisque les valeurs Epoch soient cohérentes à travers 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 31 décembre 1986, quelle que soit l'exactitude de l'idée du système de l'heure actuelle. L'expression est donnée pour garantir 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).
La "faille" permettant ce comportement:
Notez qu'en conséquence pratique, 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 les heures POSIX comme si aucune heure ne s'était écoulée. Voir cette réponse Unix StackExchange pour plus de détails sur toutes les implémentations modernes.
Ouf, c'était déroutant bien ... Un vrai casse-tête!
Étant donné que les deux autres réponses contiennent beaucoup d'informations trompeuses, je vais ajouter ceci.
Thomas a raison de dire que le nombre de secondes d'horodatage Unix Epoch par jour est fixe. Cela signifie que les jours où il y a une seconde intercalaire, la seconde juste avant minuit (la 61e seconde de la minute UTC avant minuit) reçoit le même horodatage que la seconde précédente.
Cet horodatage est "rejoué", si vous voulez. Ainsi, le même horodatage Unix sera utilisé pendant deux secondes réelles. Cela signifie également que si vous obtenez des époques fraction unix, la seconde entière se répétera.
X86399.0, X86399.5, X86400.0, X86400.5, X86400.0, X86400.5, puis X86401.0.
Donc, le temps Unix ne peut pas sans ambiguïté représenter les secondes intercalaires - l'horodatage des secondes intercalaires est également l'horodatage de la seconde précédente dans le monde réel.