Pas de seconde intercalaire ajoutée fin décembre 2026

• Selon l’IERS Bulletin C 72, aucune seconde intercalaire ne sera ajoutée à l’UTC fin décembre 2026 ; les systèmes de mesure et de diffusion du temps n’ont donc pas à préparer de traitement d’insertion particulier
• L’écart entre UTC et TAI reste maintenu à UTC-TAI = -37 s depuis le 1er janvier 2017 à 0 h UTC et jusqu’à nouvel avis
• L’introduction d’une seconde intercalaire est décidée en fonction de l’évolution de UT1-TAI, avec des dates possibles fin juin ou fin décembre
• Le Bulletin C annonce tous les six mois les échelons de temps UTC (time step) ou confirme l’absence d’échelon de temps à la prochaine date possible
• Pour la diffusion de l’UTC fin 2026, aucune nouvelle valeur de correction n’est nécessaire ; il suffit de continuer à utiliser la relation existante UTC-TAI = -37 s

---

Avis UTC de l’IERS Bulletin C 72

• Le Bulletin C 72, publié par l’IERS à Paris le 6 juillet 2026, indique qu’aucune seconde intercalaire ne sera introduite fin décembre 2026
• L’avis s’adresse aux organismes responsables de la mesure et de la diffusion du temps
• Les deux valeurs clés sont les suivantes
  • Depuis le 1er janvier 2017 à 0 h UTC et jusqu’à nouvel avis : UTC-TAI = -37 s
  • Fin décembre 2026, aucun nouvel échelon de temps ne sera appliqué à l’UTC

Décision sur les secondes intercalaires et fréquence des avis

• Une seconde intercalaire peut être introduite dans l’UTC en fonction de l’évolution de UT1-TAI
• Les dates possibles d’introduction sont chaque année fin juin ou fin décembre
• Le Bulletin C est diffusé tous les six mois
  • Il annonce tout échelon de temps appliqué à l’UTC
  • Il confirme l’absence d’échelon de temps à la prochaine date possible le cas échéant

[GN⁺]

Avis sur Hacker News

• Je me demande d’où vient cette imprévisibilité. J’aurais pensé qu’on connaissait la rotation et la révolution de la Terre à de nombreuses décimales près, mais est-ce que des facteurs comme l’activité géologique ou la météo créent des variations de vitesse de rotation qui rendent les prévisions difficiles ?

  • En bref, oui. La météo, l’activité géologique, ainsi que les déplacements d’eau dus aux humains, comme l’épuisement des aquifères et la construction de barrages, et la fonte des glaciers et des glaces, introduisent tous des variations difficiles à prévoir dans la période de rotation de la Terre et dans son axe de rotation
    De mémoire, ces modèles sont des polynômes trigonométriques de faible degré ; donc même si l’on modélisait parfaitement l’imprévisibilité, il serait difficile de les diffuser avec une très grande précision à cause de l’erreur de troncature, et comme ils sont déjà embarqués dans des systèmes comme les satellites, on ne peut pas non plus les rendre arbitrairement complexes
    À noter que les secondes intercalaires doivent bientôt disparaître, et il me semble qu’elles seront progressivement abandonnées en 2035. Je crois que le report vient du fait que la Russie a besoin de temps pour mettre à jour ses satellites GLONASS
  • Oui. Il y a ces facteurs, et beaucoup d’autres. Notre précision de mesure est bien meilleure que les variations annuelles de premier et de second ordre de la durée du jour
    https://datacenter.iers.org/singlePlot.php?plotname=Bulletin... est le graphique le plus pertinent à ce sujet, et les sauts verticaux représentent les secondes intercalaires. L’IERS propose aussi des graphiques sur d’autres dimensions de la rotation, mais celui-ci est agréable à lire
  • Justement, je venais de consulter l’article Wikipedia pour voir quand avait eu lieu la dernière seconde intercalaire, et la réponse y figure aussi
    « La vitesse de rotation de la Terre varie en réaction à des événements climatiques et géologiques ; les secondes intercalaires UTC sont donc placées de manière irrégulière et ne peuvent pas être prédites avec précision »
    https://en.wikipedia.org/wiki/Leap_second
  • C’est plutôt presque l’inverse. La rotation de la Terre peut varier de quelques secondes d’une année à l’autre, mais sur plusieurs centaines d’années, les fluctuations tendent globalement à se compenser
    C’est pourquoi je ne pense pas que tenter d’ajouter ou de retirer des secondes intercalaires soit une très bonne idée. En pratique, seuls les organismes spatiaux se soucient de ce genre de choses ; ils peuvent appliquer les corrections qu’ils veulent, sans que cela doive affecter tout le monde
    Pour le grand public, le seul impact réel de cette dérive est à peu près le GPS ; or le GPS transmet déjà le décalage par rapport à sa propre horloge pour que le récepteur puisse corriger. L’horloge GPS n’est ni l’UTC ni le TAI
  • Voir https://en.wikipedia.org/wiki/Leap_second#:~:text=Other%20co...

• Ce n’est pas plutôt de l’anti-news ? J’ai le vague souvenir qu’on a cessé d’introduire des secondes intercalaires jusqu’à nouvel ordre parce qu’elles posaient trop de problèmes aux systèmes informatiques actuels
  Aujourd’hui, l’écart est de 37 secondes, et personne n’a à craindre que Noël glisse vers la période de Pâques. Je pense qu’on peut transmettre ce problème aux générations futures de façon bien plus responsable que beaucoup d’autres
  Le fait qu’une annonce sorte tous les six mois n’est qu’une procédure destinée à respecter la formulation du traité international d’origine

  • Ce n’est pas encore le cas. Ce n’est qu’une proposition, et l’arrêt officiel a peu de chances d’arriver avant 2035
    S’il n’y a pas eu de seconde intercalaire depuis un moment, c’est parce que la dérive entre TAI et UT1 a ralenti et, en réalité, évolue très lentement dans le sens opposé
  • Le fait que le préavis ne soit que de six mois me paraît absurde, et c’est probablement une cause du problème
    Comme personne ne remarquerait que l’heure est décalée d’environ ±60 secondes, il semblerait plus gérable d’insérer arbitrairement une seconde intercalaire tous les dix ans environ et de l’annoncer dix ans à l’avance, afin de laisser à tout le monde le temps de remettre ses systèmes en ordre. Six mois pour que le monde entier se coordonne et l’exécute, c’est ridiculement optimiste

• Expliquez-moi comme si j’avais 5 ans : je me demande quel effet cela a sur les timestamps UNIX. En particulier pour les choses en mode maintenance ou presque plus maintenues
  Dans mon travail, je n’ai pas besoin de cette précision, mais il y a sûrement des domaines où elle est nécessaire

  • Les timestamps UNIX ignorent complètement les secondes intercalaires et font comme si elles n’existaient pas
    Ainsi, lorsqu’une seconde intercalaire est insérée, il peut y avoir une seconde physique impossible à référencer avec un timestamp UNIX ; et lorsqu’une seconde intercalaire est supprimée, il peut exister un timestamp UNIX correspondant à une seconde qui n’a jamais réellement existé
  • À chaque ajout de seconde intercalaire, Google ralentissait ou accélérait les horloges de ses serveurs sur une période plus longue, généralement plusieurs heures, afin de les resynchroniser progressivement avec une horloge à pendule parfaitement sphérique en platine pur située quelque part au NIST : https://developers.google.com/time/smear
  • Les résultats de time() et de clock_gettime(CLOCK_REALTIME) sont affectés par les secondes intercalaires
    Une nouvelle seconde intercalaire parvient au système via NTP. Malheureusement, NTP ne diffuse qu’un indicateur signalant qu’une seconde intercalaire va être introduite, pas le décalage lui-même. Mais comme l’heure diffusée est déjà affectée par la seconde intercalaire, le client NTP n’a pas nécessairement besoin de le savoir
    À l’inverse, d’autres méthodes de synchronisation temporelle comme GPS et PTP utilisent une échelle de temps non affectée par les secondes intercalaires et diffusent le décalage UTC comme information supplémentaire. C’est au client de corriger l’heure reçue à la fin. Le noyau dispose d’un paramètre clock_adjtime() pour les secondes intercalaires
    Sur un système autonome doté d’un client NTP, l’heure change pendant l’exécution pour s’aligner sur la nouvelle seconde intercalaire. Linux traite l’heure UTC en priorité, elle est donc enregistrée dans le périphérique RTC et conservée après redémarrage
    CLOCK_TAI semble devoir renvoyer l’heure TAI, mais sur les distributions Linux de bureau et serveur courantes, il est traité comme une fonctionnalité de second rang, au point que même le décalage n’est pas configuré et qu’il renvoie la même heure que CLOCK_REALTIME
    Dans /etc, il y a un fichier listant les secondes intercalaires, fourni par un paquet quelconque ; pour le mettre à jour, il faut une mise à jour du système. Je ne pense pas que les logiciels NTP traditionnels mettent ce paquet à jour dynamiquement. Cela dit, peu de logiciels utilisent ce fichier
    Si un script de service init le parse pour configurer le décalage UTC du noyau, le CLOCK_TAI du système peut avoir une seconde de retard sur le reste du monde jusqu’à la mise à jour. Mais à ma connaissance, cela n’a aucun effet sur l’heure UTC de Linux

• La formule « aux organismes responsables de la mesure et de la diffusion du temps » est un préambule d’anthologie

  • Mieux encore : cette organisation s’appelle International Earth Rotation Service
  • Pendant plusieurs années, à l’USNO, le titre du responsable qui supervisait divers produits de temps de précision était « Director of the Directorate of Time »
  • On dirait une expression tout droit sortie d’un roman de Douglas Adams
  • « Director Earth Orientation Center of IERS Observatoire de Paris, France »
    Même l’intitulé du poste fait SF

• Si le décalage UTC-TAI reste à -37 secondes, cela signifie que le décalage UTC-GPS reste lui aussi à -18 secondes
  TAI et GPS ont un décalage constant de 19 secondes entre les deux systèmes

• Je me demande ce qu’il advient de systèmes comme Spanner dans ce genre de situation
  Est-ce un casse-tête, ou bien un non-événement ?

  • C’est un gros problème. La façon la plus courante de le gérer s’appelle le smearing : on ajuste la durée de chaque seconde pendant les 24 heures précédant la « seconde intercalaire »
    Dans les systèmes qui exigent une garantie stricte d’ordre, cela fonctionne parce que chaque appareil reste synchronisé avec l’horloge globale, et seule la longueur du cycle de l’horloge varie très légèrement. Je crois me souvenir que c’était dans l’article original sur Spanner
    Quelques systèmes rares utilisent des secondes d’oscillateur monotone et ignorent les secondes de rotation terrestre, mais si l’on doit un jour convertir cela en heure réelle, le désastre s’accumule avec le temps, et ce n’est généralement pas considéré comme une bonne idée
  • Les secondes intercalaires ne sont pas ajoutées selon un calendrier régulier comme les jours bissextiles ; elles dépendent de mesures physiques de la Terre
    Donc j’imagine que les systèmes haute fiabilité disposant d’une gestion complète du temps ne sont pas très perturbés par ce genre de décision

• Avec la Temporal API, les navigateurs, Node.js, etc. pourront-ils gérer correctement le temps dans les calculs autour de ce moment ? Ou faudra-t-il une mise à jour pour éviter de fausser les calculs ?

  • La Temporal API semble fondée sur les horodatages Unix/POSIX, qui ignorent les secondes intercalaires. En temps Unix, une journée compte toujours 86 400 « secondes »
    Cela permet de faire facilement des calculs de calendrier UTC passés et futurs sans base de données, et sans forcément gérer les fractions de seconde. Les secondes intercalaires sont prises en charge par le système d’exploitation, soit en répétant ou en sautant une seconde, soit en ajustant la longueur des secondes sur une certaine période avant et après la seconde intercalaire
    La plupart des API de date et d’heure sont conçues avant tout pour prendre en charge les opérations de calendrier et d’horloge murale nécessaires aux fonctionnalités métier. Si vous avez besoin de secondes SI à des fins scientifiques, il faut utiliser une API et des fonctionnalités distinctes fournissant et garantissant la sémantique requise jusqu’au niveau matériel
    De même, si vous avez besoin de temporisateurs pour des fonctionnalités logicielles comme sleep sur des threads, il faut utiliser des interfaces dédiées comme une horloge monotone. La disparition progressive des secondes intercalaires ne change pas vraiment la situation. Avec ou sans ajustement par seconde intercalaire, par exemple, faire dépendre un algorithme de mutex d’un horodatage Unix était déjà une erreur, et le restera

• Écoutez-moi bien. On installe des moteurs à réaction à l’équateur et on les fait pivoter de 180 degrés pour gagner ou perdre du temps. Puis on les branche sur mon bouton snooze

  • Ce ne serait pas plus simple que Superman fasse plusieurs fois le tour de la Terre à très grande vitesse ? Comme ça, pas besoin de s’inquiéter de la maintenance des moteurs
  • En réalité, déplacer une très grande quantité d’eau pourrait avoir un effet mesurable. Par exemple en épuisant l’aquifère de la Central Valley en Californie
  • Le problème, c’est que la société du futur récupérera ces moteurs pour des vaisseaux interstellaires. Ce problème a été traité dans une série de livres de Larry Niven
  • On pourrait aussi tous sauter en même temps. Il ne faut qu’une ou deux secondes, non ?
  • Vu qu’on n’a pas eu besoin d’ajouter de seconde intercalaire pendant un bon moment, on dirait que cette méthode a fonctionné

• Il est écrit : « La différence entre UTC et TAI est UTC-TAI = -37 s à partir du 1er janvier 2017 à 0 h UTC et jusqu’à nouvel ordre »
  Cela veut-il dire que l’horloge atomique a 37 secondes de retard sur l’horloge solaire ? Je ne comprends pas non plus pourquoi 2017 est mentionné

  • C’est plutôt l’inverse
    Un jour UTC est défini comme exactement 86 400 secondes SI. Mais le jour solaire moyen réel est plus long de quelques millisecondes. À cause des irrégularités de la rotation terrestre, l’écart n’est pas constant, mais l’écart moyen devrait augmenter lentement avec le temps. Comme les secondes SI sont comptées par des horloges atomiques, UTC passe au jour suivant toutes les 86 400 secondes d’horloge atomique
    En revanche, une horloge solaire, qui passe au jour suivant chaque fois que le Soleil moyen atteint midi, passe au jour suivant quelques millisecondes plus tard qu’UTC. Le Soleil réel se déplace dans le ciel à une vitesse qui varie au cours de l’année, il faut donc utiliser le Soleil moyen
    Autrement dit, chaque période qu’une horloge solaire appellerait exactement 86 400 secondes est plus longue de quelques millisecondes selon une horloge atomique
    Cela s’accumule chaque jour, et lorsqu’on approche d’une seconde, on insère une seconde intercalaire dans UTC afin que cette journée compte 86 401 secondes au lieu de 86 400. UTC ne se contente pas de compter le temps des horloges atomiques : comme de nombreuses activités humaines sont liées à la position du Soleil dans le ciel, il doit aussi rester synchronisé avec le Soleil
    Les humains ont défini « synchronisé avec le Soleil » comme « à moins d’une seconde du Soleil moyen ». Autrement dit, on veut que midi UTC soit à moins d’une seconde du midi solaire moyen au méridien d’origine
    Les 37 secondes indiquent donc de combien le midi solaire moyen aurait eu du retard sur le midi UTC si l’on n’avait pas utilisé de secondes intercalaires. À midi UTC, il aurait encore manqué 37 secondes au Soleil moyen pour traverser le méridien d’origine dans le ciel
  • D’après Wikipédia, la dernière seconde intercalaire a été insérée en décembre 2016 : https://en.wikipedia.org/wiki/Leap_second
  • La mention de 2017 vient sans doute du fait que c’est à ce moment-là que le décalage a changé pour la dernière fois. C’est pourquoi les -37 secondes sont restées valables depuis