Fin de la seconde intercalaire : ce qui change pour vos serveurs NTP d'ici mai 2027

Par Richard DEMONGEOT | Publié le 16 octobre 2026 | Temps de lecture : 9 min

La seconde intercalaire s'arrête. La dernière restera celle du 31 décembre 2016 : le Bulletin C 72 de l'IERS (6 juillet 2026) annonce « NO leap second […] at the end of December 2026 », et rappelle qu'une seconde intercalaire ne s'introduit qu'« at the end of the months of December or June ». La date suivante, le 30 juin 2027, tombe après l'entrée en vigueur. TAI − UTC reste donc à 37 secondes.

Pour l'histoire du mécanisme, les pannes qu'il a causées et le détail du vote, voir notre page seconde intercalaire. Cet article répond à une autre question : qu'est-ce que l'administrateur d'un serveur NTP doit vérifier d'ici mai 2027 ? Ce que nous disons de chrony et de ntpd vient de leur documentation et de leur code source actuel. Aucun des deux projets n'a annoncé, au 16 octobre 2026, ce qu'il fera de son code de seconde intercalaire : nous ne le devinons pas.

1. Ce que dit la résolution, et ce qu'elle ne dit pas

La résolution 5, « sur les actions techniques requises pour assurer la continuité de l'UTC », tient en deux décisions : l'UTC continu au 20 mai 2027, et un écart |UT1-UTC| porté à 3 600 secondes, « ce qui assurera une continuité à long terme de l'UTC pendant plusieurs siècles ». Elle salue l'engagement de l'IERS « à prendre toutes les mesures nécessaires pour modifier au niveau opérationnel la façon dont sont annoncées et transmises les secondes intercalaires ».

Elle ne dit rien de NTP, ni du fichier leap-seconds.list, ni des logiciels. Parmi ses motifs, un passage concerne directement les opérateurs de temps : « l'utilisation de différentes méthodes de compensation par les fournisseurs de services mondiaux […] conduit à des incohérences dans la synchronisation des différents systèmes ». C'est le smear, lissage pratiqué notamment par Google et AWS, que la page seconde intercalaire décrit en détail.

2. Ce qui reste : le Leap Indicator

Les deux bits du Leap Indicator restent dans chaque paquet NTP : la résolution ne touche pas le protocole, défini par le RFC 5905 (§7.3).

ValeurSignificationAprès le 20 mai 2027
00Aucun avertissementLa valeur normale, en permanence
01Dernière minute du mois à 61 secondesÀ traiter comme une anomalie : plus aucune seconde ne peut être annoncée
10Dernière minute du mois à 59 secondesJamais utilisée ; à traiter de même comme une anomalie
11Horloge non synchroniséeInchangé : l'alarme garde son usage

« Du mois » suit la définition du champ (RFC 5905, §7.3) et le RFC 8633 (§3.7), selon lequel la seconde ne s'applique que le dernier jour du mois ; la figure 9 du RFC 5905 écrit, elle, « last minute of the day » (détail).

Ce point compte parce que la liste locale ne fait pas barrage seule. La documentation de chrony le dit : si une majorité de sources annonce une seconde intercalaire le dernier jour de juin ou de décembre, « it will be accepted even if it is not included in the timezone ». Côté ntpd, le code (ntp_proto.c et ntp_leapsec.c) accepte une annonce portée par plus de la moitié de ses sources retenues, mais seulement si sa table locale a expiré. Deux réflexes, donc : garder des sources qui suivent la liste de l'IERS, et surveiller l'état. 

# chrony : l'état attendu est « Normal »
chronyc tracking | grep 'Leap status'
Leap status     : Normal

# ntpd ou NTPsec : leap=00
ntpq -c 'rv 0 leap'

3. leap-seconds.list : l'échéance du 28 juin 2027

Le fichier leap-seconds.list, tenu par l'IERS et redistribué par la base tz de l'IANA (paquet tzdata), porte une date d'expiration sur sa ligne #@, en secondes depuis 1900. La version en cours expire le 28 juin 2027, soit cinq semaines après l'entrée en vigueur de l'UTC continu. Pour la lire sur un serveur : 

date -u -d @$(( $(awk '/^#@/{print $2}' /usr/share/zoneinfo/leap-seconds.list) - 2208988800 )) +%F
2027-06-28

Ce que font les logiciels d'une liste expirée, d'après leur code actuel :

  • chrony (leapdb.c) : une fois l'échéance passée, il journalise « Leap second list … needs update » et continue d'utiliser le contenu du fichier. La dernière entrée, TAI − UTC = 37 s au 1er janvier 2017, reste juste.
  • ntpd (ntp_util.c) et NTPsec (ntp_util.c) : un avertissement par jour pendant les 28 jours qui précèdent l'échéance (« will expire in less than N days »), puis une erreur par jour après (« expired N days ago »). Table expirée, ntpd accepte de nouveau une annonce majoritaire de ses sources (section 2).

La suite dépend de l'IERS. Le 15 octobre 2026, le coordinateur de la base tz, Paul Eggert, a écrit au directeur du centre de l'IERS qui maintient le fichier ; il s'attend à ce que l'échéance soit retirée ou repoussée loin dans le futur. Au 16 octobre, aucune nouvelle version n'est publiée.

4. leapsectz de chrony : vérifier qu'il lit quelque chose

chrony connaît deux sources locales. leapsectz right/UTC interroge un fuseau horaire de la base tz qui contient les secondes intercalaires ; leapseclist, ajoutée dans chrony 4.6 (NEWS), lit directement leap-seconds.list. Sous Debian 13, right/UTC est absent par défaut (constaté sur nos serveurs) : les fuseaux right/ sont passés dans le paquet tzdata-legacy, non installé par défaut (changelog de tzdata, version 2023c-7), et le chrony.conf fourni par Debian utilise déjà leapseclist sur leap-seconds.list (changelog de chrony, version 4.6~pre1-1). Une configuration plus ancienne ou gérée à part qui garde leapsectz right/UTC ne lit alors plus rien, et chrony l'écarte au démarrage avec « Timezone right/UTC failed leap second check, ignoring ».

La documentation donne le test, à lancer sur chaque serveur qui garde leapsectz : 

TZ=right/UTC date -d 'Dec 31 2008 23:59:60'
Wed Dec 31 23:59:60 UTC 2008     # le fuseau contient les secondes intercalaires

# sinon, remplacer par (chrony 4.6 ou plus récent) :
leapseclist /usr/share/zoneinfo/leap-seconds.list

Une source locale garde son utilité après mai 2027. D'après la documentation, elle sert aussi quand l'horloge système doit porter le bon écart TAI − UTC (le noyau ne le reçoit qu'avec leapsecmode system), ce qui compte pour les applications qui lisent CLOCK_TAI. Et c'est elle qui permet de reconnaître une annonce erronée (section 2). Notre propre configuration est décrite dans la politique de nos serveurs.

5. Le smear sert-il encore ?

Le lissage ne s'applique qu'autour d'une seconde intercalaire. Google le dit de son service : « Before and after this period, smeared clocks and time service agree with clocks » qui suivent UTC (Google Public NTP, Leap Smear). Sans seconde intercalaire après le 20 mai 2027, il n'y a plus de période de lissage.

  • Sources qui lissent (time.google.com, Amazon Time Sync) : le risque de les mêler à des sources conformes n'existait que pendant la fenêtre. Rien à retirer, la page seconde intercalaire détaille ce point.
  • chrony : smoothtime … leaponly ne lisse que les secondes intercalaires, il n'aura plus rien à lisser. Sans leaponly, la directive garde un usage documenté distinct : adoucir pour les clients les grosses corrections d'horloge du serveur, par exemple après une longue coupure.
  • ntpd : leapsmearinterval reste une option expérimentale, présente seulement si ntpd a été compilé avec --enable-leap-smear (documentation ntpd).

6. Ce que l'administrateur doit vérifier

  1. La source locale existe. La directive leapseclist (chrony) ou leapfile (ntpd) pointe vers un fichier présent, et chrony écrit au démarrage « Using leap second list … » ; ntpd, « leapsecond file (…): loaded, expire=… ».
  2. Pas de leapsectz orphelin. Le test TZ=right/UTC de la section 4 répond 23:59:60, ou la directive est remplacée.
  3. La mise à jour de tzdata est planifiée avant le 28 juin 2027, avec une alerte sur « needs update » (chrony) et sur « will expire in less than » (ntpd, NTPsec) dans les journaux.
  4. L'état leap est surveillé. Leap status : Normal ou leap=00 ; après le 20 mai 2027, toute autre valeur que 00 ou 11 devrait être traitée comme un incident de source, puisque plus aucune seconde intercalaire ne peut être annoncée.
  5. Les applications n'ont rien à changer pour l'heure courante : le temps Unix n'a jamais compté les secondes intercalaires. Pour convertir des horodatages anciens, la table reste nécessaire ; le convertisseur de timestamp donne l'écart TAI − UTC en vigueur à une date donnée.

7. Le calendrier

DateÉvénementSource
31 décembre 201627e et dernière seconde intercalaire ; TAI − UTC = 37 sIERS
6 juillet 2026Bulletin C 72 : pas de seconde intercalaire fin décembre 2026IERS
15 octobre 2026Résolution 5 adoptée par la 28e CGPMBIPM
20 mai 2027UTC continu en vigueurBIPM
28 juin 2027Expiration de la version actuelle de leap-seconds.listIANA

Sources

Questions fréquentes

Faut-il changer la configuration NTP avant mai 2027 ?

Pas pour la résolution elle-même : elle ne touche pas le protocole NTP. Il faut en revanche vérifier trois choses : que chrony ou ntpd lisent bien une liste de secondes intercalaires qui existe (leapseclist ou leapfile), que l'ancien leapsectz right/UTC ne pointe pas vers un fuseau absent, comme sous Debian 13, et que tzdata sera mis à jour avant le 28 juin 2027, date d'expiration de la liste actuelle.

Que se passe-t-il quand leap-seconds.list expire le 28 juin 2027 ?

Dans leur code actuel, chrony journalise « Leap second list … needs update » et continue d'utiliser le contenu du fichier ; ntpd et NTPsec avertissent chaque jour pendant les 28 jours qui précèdent l'échéance, puis signalent une erreur chaque jour après. Le 15 octobre 2026, le coordinateur de la base tz a demandé à l'IERS de retirer ou de repousser l'échéance ; au 16 octobre, aucune nouvelle version n'est publiée.

Le leap smear sert-il encore après la fin de la seconde intercalaire ?

Le lissage des secondes intercalaires n'agit que pendant une fenêtre de seconde intercalaire : Google indique qu'en dehors de cette fenêtre, ses horloges lissées sont d'accord avec UTC. Sans seconde intercalaire après le 20 mai 2027, il n'y a plus de fenêtre. La directive smoothtime de chrony sans l'option leaponly garde un autre usage, documenté : lisser les grosses corrections d'horloge du serveur.

Le Leap Indicator disparaît-il du protocole NTP ?

Non. La résolution 5 de la CGPM ne modifie pas le protocole : les deux bits du Leap Indicator restent définis par le RFC 5905. La valeur 11, horloge non synchronisée, garde son usage. Les valeurs 01 et 10 annoncent une seconde à ajouter ou à retirer ; après le 20 mai 2027, elles devraient être traitées comme une anomalie, puisque plus aucune seconde intercalaire ne peut être annoncée.