Le temps écoulé depuis l’époque

• Le temps POSIX / Unix time est souvent présenté comme le nombre de secondes depuis le 1970-01-01 00:00:00, mais en réalité il s’agit d’une valeur basée sur l’UTC qui ignore les secondes intercalaires, ce qui le décale du nombre réel de secondes écoulées
• Au 2024-12-25 18:51:26 UTC, le temps POSIX vaut 1735152686, tandis que le nombre réel de secondes écoulées depuis l’époque est de 1735152713, soit un écart de 27 secondes
• Lorsqu’IEEE 1003.1 définit seconds since the Epoch, une journée est toujours calculée comme 86 400 secondes, et l’annexe de la norme ignore également les 14 secondes intercalaires ajoutées depuis 1970 pour des raisons de compatibilité et de simplicité de calcul
• L’UTC ajoute des secondes intercalaires pour limiter l’écart avec le jour solaire, et à ces moments-là le temps POSIX peut sauter en arrière, ce qui a déjà provoqué des incidents sur Linux, chez Qantas ou encore sur le DNS de Cloudflare
• Pour mesurer des intervalles de temps sur une seule machine, il vaut mieux utiliser CLOCK_MONOTONIC ou CLOCK_BOOTTIME, et si l’on doit rester aligné avec des timestamps POSIX, il faut envisager le leap smear ou une conversion POSIX↔TAI

---

Le temps POSIX n’est pas le nombre réel de secondes écoulées

• Date en JavaScript, GNU coreutils, time(2) sous Linux, time.Unix en Go, datetime dans MySQL, Time en Ruby, timestamp dans Cassandra, etc. traitent souvent le temps POSIX comme s’il s’agissait du nombre de secondes depuis l’epoch Unix
• Mais cette formulation ne correspond pas exactement à l’intuition courante ni à la réalité
  • Heure d’exemple : 2024-12-25 18:51:26 UTC
  • Temps POSIX : 1735152686
  • Nombre réel de secondes écoulées depuis l’epoch POSIX : 1735152713
  • Écart : 27 secondes
• Cette différence vient du fait que le temps POSIX est dérivé de l’IEEE 1003.1 et de l’UTC, tout en supposant que chaque jour dure exactement 86 400 secondes
• La définition de seconds since the Epoch dans la norme calcule la valeur à partir de tm_sec, tm_min, tm_hour, tm_yday et tm_year, sans définir sa relation avec les années antérieures à 1970 ni avec des valeurs négatives
• En réalité, une journée ne dure pas toujours 86 400 secondes et sa durée varie selon les périodes
  • Les astronomes déclarent périodiquement des secondes intercalaires afin que la date UTC ne s’éloigne pas trop du jour solaire
  • En conséquence, le temps POSIX peut sauter en arrière tous les quelques années
  • Un jour, il pourrait aussi sauter en avant
• Les secondes intercalaires ont déjà causé de vrais incidents
  • Problème de seconde intercalaire lié au noyau Linux
  • Retards chez Qantas dus à un bug Linux lié aux secondes intercalaires
  • Impact d’une seconde intercalaire sur le DNS de Cloudflare

Les compromis de la norme et les alternatives en pratique

• L’annexe B d’IEEE 1003 résume qu’au moment de la publication de la norme, 14 secondes intercalaires avaient été ajoutées depuis le 1970-01-01, mais qu’elles étaient ignorées pour faciliter les calculs et préserver la compatibilité
• La norme part du principe que la valeur “time” de la plupart des systèmes continue d’augmenter, et choisit donc qu’elle continue à croître même pendant une seconde intercalaire
  • Elle suppose en même temps que la plupart des systèmes ne suivent pas les secondes intercalaires ou ne sont pas nécessairement synchronisés sur une référence horaire standard
  • Elle n’exige donc pas que seconds since the Epoch représente obligatoirement le nombre exact de secondes entre l’epoch et l’instant de référence
  • Il suffit que les applications puissent traiter cette valeur comme un nombre de secondes depuis l’epoch, la précision nécessaire relevant des fournisseurs système et des administrateurs
• Dans les applications distribuées, les événements sont synchronisés par des timestamps, donc une interprétation cohérente peut devenir importante
  • L’accumulation des secondes intercalaires n’est pas prévisible
  • Leur nombre depuis l’epoch peut encore augmenter
  • La norme s’intéresse davantage à la synchronisation temporelle entre applications sur des périodes astronomiquement courtes
• En pratique, les systèmes fonctionnent généralement même si l’heure est légèrement décalée, mais comme les secondes intercalaires sont rares et que l’intuition d’un temps linéaire en secondes depuis l’epoch est très forte, des bugs non détectés peuvent s’accumuler
• Les alternatives dépendent du cas d’usage
  • Si l’on calcule seulement une durée entre deux événements sur une même machine, utiliser CLOCK_MONOTONIC, voire CLOCK_BOOTTIME
  • S’il n’est pas nécessaire d’échanger des timestamps avec d’autres systèmes supposant du temps POSIX, utiliser TAI, GPS, LORAN
  • S’il faut rester approximativement aligné avec des systèmes à timestamps POSIX, utiliser le leap smear pour répartir la seconde intercalaire sur une période plus longue
  • Des bibliothèques comme t-a-i de qntm permettent de convertir entre POSIX et TAI
• Des efforts pour abolir les secondes intercalaires sont en cours, avec l’espoir d’y parvenir d’ici 2035
  • Cela nécessitera un travail supplémentaire pour intégrer des tables de conversion partout où l’on dépend de l’hypothèse une journée = 86 400 secondes
  • Pour les dates postérieures à 2035, des questions comme « combien de secondes y a-t-il entre deux instants ? » pourraient devenir beaucoup plus simples

[GN⁺]

Commentaires de Hacker News

• Je viens de lire le roman de science-fiction de Vernor Vinge paru en 2000, A Deepness in the Sky, et c’est un excellent livre où l’on trouve une allusion inattendue aux secondes écoulées depuis l’epoch
  Cela commence par « Regardez la façon dont les Traders mesurent le temps… » et décrit comment les Qeng Ho comptent les secondes depuis l’instant où l’humanité a posé le pied pour la première fois sur la Lune de la Vieille Terre, mais qu’en y regardant de plus près, le point de départ se situe en réalité environ 15 millions de secondes plus tard, au temps zéro de l’un des premiers systèmes d’exploitation informatiques de l’humanité

  • Ce livre fait personnellement partie de mes préférés de tous les temps, et j’aime beaucoup sa manière d’utiliser des références logicielles discrètes
    Si vous voulez davantage d’« informatique dans l’espace », je recommande la série Bobiverse ; si vous voulez davantage d’exploration « humains + simulation + ordinateurs », je recommande Permutation City

• Chaque fois que je lis quelque chose sur la mesure du temps, j’apprends invariablement quelque chose de nouveau. J’ai toujours pensé que le temps Unix était la manière la plus simple de suivre le temps, à condition de tenir compte du rollover, et je connaissais les secondes intercalaires, mais je n’avais pas pensé qu’elles s’appliquaient aussi ici
  J’ai aussi lu le lien « UTC, GPS, LORAN and TAI », et le fait que le temps GPS ne tienne pas compte des secondes intercalaires offre un contraste intéressant

  • Dire qu’un événement s’est produit quelques secondes avant/après est simple. Le plus difficile est d’attribuer à cet instant une date de calendrier
  • En fin de compte, j’en viens à considérer que TAI est le plus simple, et que les autres formats ne devraient être utilisés qu’en les convertissant depuis TAI lorsque c’est nécessaire, par exemple pour l’affichage ou l’interopérabilité

• Je n’aime pas vraiment le projet visant à « supprimer les secondes intercalaires d’ici 2035 »
  Le principe d’UTC est d’être décalé de TAI d’un nombre entier de secondes afin de rester proche du temps solaire moyen (MST). Si l’on ne veut plus suivre le MST, autant passer simplement à TAI
  Si l’on laisse UTC s’éloigner du MST, il faudra toujours gérer les secondes intercalaires passées, mais elles n’auront plus vraiment de raison d’être : une situation bancale

  • Je suis d’accord pour dire que s’éloigner du MST coûte plus que cela ne rapporte
    Cela dit, cette proposition n’est pas totalement dénuée de sens. L’objectif est de ne pas modifier la gestion actuelle du temps UTC, tout en faisant en sorte que la différence entre deux horodatages postérieurs à 2035 corresponde au nombre exact de secondes physiques
    Malgré tout, puisque le MST fait déjà partie de la fonction d’UTC, le supprimer paraît absurde
  • Dans un monde idéal, les systèmes informatiques auraient dû utiliser TAI pour suivre le temps, puis convertir vers UTC ou l’heure locale à l’aide de la base de données TZ
    Mais dans la réalité, beaucoup de systèmes ont fait le mauvais choix, UNIX étant le principal responsable. Ce choix est si profondément ancré dans d’innombrables systèmes et réglementations que « passer simplement à TAI » est pratiquement impossible
    Il est donc plus facile de réinterpréter UTC comme le « nouveau TAI ». Je ne serais pas surpris qu’un jour l’ancien UTC réapparaisse sous un autre nom
  • Il n’existe pas d’entité distincte appelée TAI. TAI s’obtient en partant d’UTC et en soustrayant le nombre de secondes intercalaires qui nous intéressent. TAI n’est pas maintenu comme une grandeur standard séparée
    Dans la plupart des pays, voire tous, l’heure civile est fondée sur UTC. On ne va pas reculer toutes les horloges du monde d’environ 30 secondes au motif que ce serait un peu plus pur
    Le temps GPS a lui aussi un décalage avec TAI, mais personne ne s’en préoccupe vraiment. Il en va de même pour l’epoch Unix : tant que le résultat est cohérent, cela suffit
  • Le hack est littéralement trivial. Une fois par mois, il suffit de vérifier si UTC # ET ; si ce n’est pas le cas, on crée un fichier appelé Leap_Second. Chaque mois, on regarde si ce fichier existe ; s’il existe, on le supprime, on ajoute 1 à la valeur du fichier Leap_Seconds, puis on crée une sauvegarde appelée LSSE
    « You are not expected to understand this. » C’est une façon de maintenir les deux systèmes. Si on le souhaite, on peut aussi le faire avec un hash ou une table de correspondance

• Il est aussi important de noter que l’epoch UTC moderne est le 1er janvier 1972. Avant cela, UTC utilisait une longueur de seconde différente de TAI
  Fin 1971, comme étape intermédiaire, il y a eu un dernier saut irrégulier de exactement 0,107758 seconde TAI, et les petites marches temporelles ainsi que les ajustements de fréquence d’UTC ou de TAI entre 1958 et 1971 ont été calibrés pour totaliser exactement 10 secondes. Ainsi, le 1er janvier 1972 à 00:00:00 UTC correspondait exactement au 1er janvier 1972 à 00:00:10 TAI, et depuis lors l’écart est un nombre entier de secondes
  Dans le même temps, le rythme des ticks d’UTC est devenu exactement le même que celui de TAI, et UTC a commencé à suivre UT1 plutôt qu’UT2. Par conséquent, le temps Unix de 1970 et 1971 ne correspond pas au temps UTC réel de cette période
  https://en.wikipedia.org/wiki/Coordinated_Universal_Time#His...
  https://en.wikipedia.org/wiki/Unix_time#UTC_basis

  • À cause de cela, certaines personnes vivantes aujourd’hui ne peuvent pas connaître leur âge exact en secondes, et ne le pourront jamais
    Même en supposant que l’heure figurant sur leur acte de naissance soit exacte à la seconde près. Pendant une partie de leur vie, la valeur considérée comme la « durée d’une seconde » était assez différente de celle que nous avons généralement en tête aujourd’hui
    Ici, par seconde, on entend la seconde définie à partir de la fréquence de transition hyperfine de l’état fondamental non perturbé de l’atome de césium 133, soit 9 192 631 770 Hz

• J’ai récemment travaillé sur du code destiné à une bourse, et ce système tournait sur VAX, ou plus précisément sur OpenVMS, avec une epoch fixée au 17 novembre 1858.
  C’était la première fois dans ma carrière que je voyais une epoch non Unix, et heureusement, le code que nous utilisions l’abstrayait en epoch Unix.

  • L’epoch de 1858 semble venir du jour julien, le calendrier standard en astronomie. Son jour 0 correspond à l’an 4713 av. J.-C.
    https://www.slac.stanford.edu/~rkj/crazytime.txt
    Pour faire tenir ces dates dans la mémoire des ordinateurs des années 1950, le calendrier a été décalé de 2,4 millions de jours, ce qui a placé le jour 0 au 17 novembre 1858.
  • Il y a aussi une vieille anecdote de Microsoft sur le conflit entre l’epoch d’Excel, le 1er janvier 1900, et celle de Basic, le 31 décembre 1899.
    https://www.joelonsoftware.com/2006/06/16/my-first-billg-rev...
  • Autre système informatique courant à connaître : la Windows epoch est le 1er janvier 1601.
  • Classic Mac OS, le système de fichiers HFS d’Apple (également utilisé sous OS X) et PalmOS avaient tous pour epoch le 1er janvier 1904.
    L’API Foundation macOS/Swift NSDate.timeIntervalSinceReferenceDate utilise le 1er janvier 2001 comme epoch.
    Wikipédia propose aussi une liste utile : https://en.wikipedia.org/wiki/Epoch_(computing)#Notable_epoc...
  • PostgreSQL utilise en interne une epoch 2000-01-01 pour stocker les horodatages.

• Certains instants ne peuvent pas être représentés par un timestamp POSIX, et certains timestamps POSIX ne correspondent à aucun temps réel.

  • Je me demande quels timestamps POSIX ne correspondent pas à un temps réel. Ou bien est-ce que cela fait référence à un éventuel futur seconde intercalaire négative ?
  • Cela a toujours été le cas. Dans le temps Unix, ce qui est antérieur à 1970 n’est pas défini.
  • Au moins, aucun timestamp POSIX ne correspond à plus d’un instant réel. C’est mieux qu’un format unique que les gens utiliseraient pour tout.
  • Ce n’est pas vrai.
    C’est un peu comme dire qu’il existe des instants sans année ISO 8601. Tous les instants ont une année, simplement certaines années sont plus longues que d’autres.
    Si vous restez assis à regarder https://time.is/UTC, le temps augmentera de façon monotone, et de temps en temps une seconde sera juste un tout petit peu plus longue. Par exemple, environ 0,001 % plus longue sur 24 heures.

• Quand je stocke des dates dans une base de données, je les enregistre toujours en temps epoch Unix, et je ne mets pas d’information de fuseau horaire dans le champ de date. Si le besoin de connaître le fuseau existe, je le stocke séparément.
  Je me demande plutôt s’il faudrait stocker les timestamps au format TAI, puis utiliser une fonction de conversion vers UTC quand c’est nécessaire, afin de gérer les corrections liées à la Terre au bon moment.
  Je sais que les fuseaux horaires sont un champ de mines, mais eux aussi sont une construction humaine dont les frontières changent avec le temps. Il me semble qu’il faudrait se caler sur un temps absolu, puis rendre dans le format horaire local souhaité lorsque c’est nécessaire.

  • Oui. TAI ou un format similaire est la seule manière raisonnable de suivre l’heure « système », et les systèmes de plus haut niveau devraient la convertir en heure lisible par les humains.
    Les ajustements liés aux secondes intercalaires devraient se faire au même endroit que les conversions de fuseau horaire. Malheureusement, Unix a standardisé la mauvaise chose, et migrer est difficile.
  • En général non, et presque jamais. La plupart des logiciels sont écrits pour lisser les secondes intercalaires, et en pratique cela ne se produit qu’au niveau de la synchronisation des horloges. Par exemple, chrony implémente le lissage des secondes intercalaires.
    Donc toutes les horloges sont de toute façon alignées sur UTC. Convertir d’UTC vers TAI à l’écriture, puis revenir en arrière à la lecture, deviendrait un bazar.
  • À propos de « ne pas enregistrer d’information de fuseau horaire dans le champ de date », en réalité très peu de bases de données permettent de préserver le fuseau horaire dans une colonne de timestamp.
    En général, soit la base de données n’a aucune notion de fuseau horaire pour les timestamps stockés (SQL Server), soit elle propose un type de timestamp « conscient du fuseau horaire » mais convertit l’entrée en UTC et jette le fuseau d’origine (MySQL, Postgres).
    À ma connaissance, seul Oracle peut réellement conserver à l’aller-retour un fuseau non local avec le type with time zone.
  • Cela dépend de ce que le système stocke. La plupart des systèmes se moquent d’avoir une erreur d’une seconde tous les quelques ans.
    Dans certains calculs, une seconde d’écart est un gros problème. Il faut être prudent quand on adopte autre chose que le format le plus répandu, et avoir une bonne raison de s’écarter du standard. Le simple fait d’être différent peut déjà coûter cher.
  • Il suffit d’utiliser les champs date-heure natifs de la base de données.

• Cet article me donne l’impression qu’on a gâché Noël. Plus rien n’est sacré ? Une seconde devrait être une seconde depuis l’epoch.
  Je ne vois pas pourquoi il faudrait se soucier du léger écart avec le jour solaire. Le convertisseur qui transforme les secondes depuis l’epoch en représentation de date ne devrait-il pas être responsable des corrections ?

  • La façon actuelle de faire est justement celle que nous voulons. 86400 secondes = 1 jour, et nous fonctionnons avec l’hypothèse que minuit UTC est toujours un multiple de 86400.
    Nous ne voulons pas obliger tous les logiciels à coder en dur l’introduction des secondes intercalaires, à gérer le lissage, et à exiger une méthode de mise à jour dans le mois qui suit l’annonce d’une nouvelle seconde intercalaire.
    Jusqu’ici, nous n’avons pas eu à nous en inquiéter ni même à y penser, et nous n’aurons pas à le faire à l’avenir. C’est géré de la bonne manière.

• Les secondes intercalaires devraient être remplacées par de grosses fusées montées sur l’équateur. N’ajustons pas les horloges, ajustons la planète.

  • Si une erreur de calcul ralentissait ou accélérait trop la Terre, ce ne serait probablement pas très drôle.
    Dans la tradition islamique, il existe aussi un passage sur la fin des temps et l’Antéchrist (Dajjal) où quelque chose de ce genre se produit réellement. Il est dit que « le premier jour de l’Antéchrist sera comme une année, son deuxième jour comme un mois, et son troisième jour comme une semaine » ; beaucoup l’interprètent littéralement, comme un événement cosmique où la rotation de la Terre ralentirait effectivement, puis finirait par s’inverser, faisant se lever le soleil à l’ouest. Ce serait le dernier signe de la fin de l’humanité.

• Même si, à cause des secondes intercalaires, l’epoch se retrouve 29 secondes plus loin dans le passé que ce que laisse entendre date +%s, j’ai du mal à voir en quoi c’est important.
  Le fait que tout le monde soit d’accord sur un certain nombre N représentant l’heure actuelle est bien plus important. Ces -29 secondes imaginaires n’ont pas d’impact sur le monde réel. On ne va pas non plus exécuter une routine de visée de missile sur une cible d’il y a 30 ans.
  Je suis pour la suppression des secondes intercalaires, mais je ne pense pas qu’il soit utile d’insister sur l’incohérence temporelle. Même si, à strictement parler, c’est vrai.

  • On peut imaginer un cas où l’on calcule la durée d’un événement court à partir de son heure de début et de fin. Si l’intervalle traverse une seconde intercalaire, la durée peut varier sensiblement selon la manière dont les horodatages sont traités.
    Le plus important, c’est l’impact sur l’avenir. Le fait que d’anciens horodatages puissent différer de quelques secondes d’un simple calcul « maintenant - N secondes » relève surtout de l’anecdote intéressante, mais le fait qu’à un moment futur toutes les horloges puissent devoir se décaler à nouveau d’une seconde est plus important. Il existe de nombreux cas réels où en tenir compte demande un effort considérable.
  • C’est important pour certaines choses. Sans ces secondes intercalaires imaginaires, par exemple, la position du soleil à midi local serait décalée de 29 secondes.