2 points par GN⁺ 2024-12-27 | 1 commentaires | Partager sur WhatsApp
  • Les secondes depuis l’époque

    • On dit souvent que le temps POSIX, ou temps Unix, désigne le nombre de secondes écoulées depuis le 1er janvier 1970 à 00:00:00. Mais ce n’est pas exact. Par exemple, le temps POSIX pour le 25 décembre 2024 à 18:54:53 UTC est 1735152686, soit 29 secondes de moins que les 1735152715 secondes réellement écoulées.

    • Le temps POSIX est dérivé du temps universel coordonné (UTC) dans la norme IEEE 1003.1. Cette norme suppose que chaque jour dure exactement 86 400 secondes. En réalité, ce n’est pas le cas, et la durée d’une journée varie au fil du temps. Pour corriger cela, les astronomes déclarent périodiquement des secondes intercalaires dans l’UTC.

  • Archéologie

    • L’annexe B de l’IEEE 1003 contient une discussion intéressante sur les secondes intercalaires. Au moment de la publication de la norme, 14 secondes intercalaires avaient été ajoutées depuis le 1er janvier 1970. Elles ont été ignorées pour faciliter le calcul des différences de temps.

    • La plupart des systèmes considèrent le temps comme une valeur qui augmente continuellement. Mais la plupart ne suivent pas les secondes intercalaires et ne sont pas synchronisés sur une référence horaire standard. Exiger que les secondes depuis l’époque représentent exactement les secondes entre le temps de référence et l’époque n’est donc pas approprié.

    • Une interprétation cohérente des secondes depuis l’époque peut être importante pour certains types d’applications distribuées. L’accumulation des secondes intercalaires est imprévisible, et leur nombre depuis l’époque continuera probablement d’augmenter.

  • Que faire à la place

    • Pour calculer la durée entre deux événements sur un même ordinateur, il faut utiliser CLOCK_MONOTONIC. Si vous n’avez pas besoin d’échanger du temps POSIX avec d’autres systèmes, vous pouvez utiliser TAI, GPS ou LORAN.

    • Si vous avez besoin d’un alignement approximatif avec le système d’horodatage POSIX, vous pouvez répartir les secondes intercalaires sur une fenêtre temporelle plus large. Des bibliothèques comme qntm t-a-i prennent en charge la conversion entre POSIX et TAI.

    • Des efforts sont en cours pour supprimer les secondes intercalaires, avec l’espoir d’y parvenir d’ici 2035. Cela demandera du travail supplémentaire pour construire des tables de conversion pour tout ce qui repose sur l’hypothèse « 86 400 secondes par jour », mais il sera alors plus simple de demander combien de secondes séparent deux instants. Au moins pour les dates postérieures à 2035.

1 commentaires

 
GN⁺ 2024-12-27
Commentaires sur Hacker News
  • J’ai lu un livre de SF intitulé "A Deepness in the Sky". La mention des secondes écoulées depuis l’époque m’a paru intéressante

    • La méthode de mesure du temps des Qeng Ho était complexe, et le comptage des secondes commençait au moment où l’humanité a posé le pied sur la Lune pour la première fois
    • Le moment de départ était en réalité environ 15 millions de secondes plus tard, ce qui correspondait à la seconde 0 des premiers systèmes d’exploitation
  • Des efforts sont en cours pour supprimer les secondes intercalaires, avec l’espoir que ce soit achevé d’ici 2035

    • Le but de l’UTC est d’être décalé du TAI d’un nombre entier de secondes afin d’approximer le temps solaire moyen
    • Si l’on ne veut pas suivre le temps solaire moyen, il faut passer au TAI, et si l’UTC s’éloigne du temps solaire moyen, les secondes intercalaires historiques perdent leur sens
  • L’« époque UTC » moderne est le 1er janvier 1972

    • À la fin de 1971, il y a eu un saut irrégulier de 0,107758 seconde TAI, puis la cadence des ticks de l’UTC a été modifiée pour correspondre exactement à celle du TAI
    • Le temps Unix de 1970 et 1971 ne correspond en réalité pas au temps UTC de cette période
  • Chaque fois que je lis quelque chose sur la mesure du temps, j’apprends quelque chose de nouveau

    • Je pensais que le temps Unix était la méthode la plus simple pour suivre le temps
    • Je pensais qu’il n’appliquait pas les secondes intercalaires, mais je n’y avais sans doute pas assez réfléchi
  • J’ai récemment travaillé sur du code pour VAX, ou s’exécutant sur OpenVMS, et c’était la première fois que je voyais une époque fixée au 17 novembre 1858

    • Dans le code, c’était abstrait en époque Unix
  • Certains instants ne peuvent pas être représentés par un timestamp POSIX, et certains timestamps POSIX ne correspondent à aucun instant réel

  • Je pense que cet article a gâché Noël

    • Les secondes devraient être des secondes depuis une époque, et peu importe qu’elles s’écartent du jour solaire
    • Le convertisseur seconde-temps de référence devrait se charger des corrections
  • Quand je stocke des dates dans une base de données, je les enregistre toujours en temps d’époque Unix, et je conserve séparément les informations de fuseau horaire

    • Je me demande s’il ne vaudrait pas mieux stocker les timestamps au format TAI, puis les convertir en UTC si nécessaire
    • Les fuseaux horaires sont un concept créé par les humains et ajusté au fil du temps
    • Il faut partir d’un temps absolu, puis convertir au format horaire local quand c’est nécessaire
  • Lors d’une conférence il y a une dizaine d’années, j’ai entendu dire que Google n’utilisait pas les secondes intercalaires et les répartissait à la place sur des secondes normales

    • Google modifie ses serveurs NTP pour répartir la seconde intercalaire
  • Je me demande s’il existe une façon de mesurer le temps qui soit à la fois synchronisée et monotone croissante