Seconde Intercalaire NTP : leap second, smear, incidents et vote de 2026

La seconde intercalaire (en anglais leap second) est l'un des mécanismes les plus subtils et les plus redoutés du protocole NTP. Depuis 1972, elle compense les irrégularités de la rotation terrestre pour maintenir UTC en phase avec le temps astronomique UT1. Pour un opérateur de serveurs NTP, chaque événement a été une répétition de crise : une annonce à surveiller, un plan de bascule, et des logs à scruter pendant les heures suivantes.

Cette page couvre ce que tout opérateur ou administrateur NTP doit comprendre : l'origine du mécanisme, les 27 secondes intercalaires ajoutées depuis 1972 et les pannes qu'elles ont provoquées, la façon dont NTP les signale, les deux approches concurrentes (step et smear), comment savoir ce que font vos serveurs amont, le comportement de chrony et ntpd, la politique appliquée sur nos serveurs, et le vote du 15 octobre 2026 qui doit décider de la fin du mécanisme.

1. Pourquoi la Terre nous oblige à ajouter des secondes

UTC (Temps Universel Coordonné) est défini depuis 1972 comme le compte des secondes SI émises par un ensemble d'horloges atomiques. UT1, lui, est le temps défini par la rotation réelle de la Terre, mesuré par interférométrie VLBI sur des quasars lointains. Les deux divergent parce que la rotation terrestre n'est pas régulière : frottement des marées, redistribution des masses internes, interactions noyau-manteau. Entre 1972 et 2016, la Terre tournait en moyenne un peu moins vite que ne le suppose UTC, et l'écart s'accumulait au rythme d'environ une seconde tous les un à deux ans.

L'IERS (Service international de la rotation terrestre et des systèmes de référence) surveille cette dérive et, pour que l'écart |UT1 − UTC| reste sous 0,9 seconde, son centre de l'Observatoire de Paris publie deux fois par an un Bulletin C qui annonce, environ six mois à l'avance, s'il y aura ou non une seconde intercalaire. L'événement a lieu en priorité le 30 juin ou le 31 décembre : la seconde 23:59:60 est insérée (une minute à 61 secondes), puis vient 00:00:00 du jour suivant.

2. Les 27 secondes intercalaires depuis 1972

De 1972 à fin 2016, 27 secondes intercalaires ont été ajoutées. Toutes positives. Les cinq dernières, que le fondateur de RDEM Systems a traversées en exploitant des serveurs NTP publics depuis 2005 :

Depuis le 1^er janvier 2017, la différence TAI − UTC est restée fixée à 37 secondes. Aucune seconde intercalaire n'a été ajoutée depuis 9 ans — un record historique dû à l'accélération de la rotation terrestre. Le dernier bulletin, Bulletin C 72 du 6 juillet 2026, l'écrit en toutes lettres : « NO leap second will be introduced at the end of December 2026 ».

3. Ce que la seconde 23:59:60 a cassé : les incidents documentés

Le protocole NTP a toujours su transporter la seconde intercalaire. Ce qui a cassé, chaque fois, c'est un logiciel qui supposait qu'une seconde ne se répète jamais et que le temps ne recule pas. Les incidents ci-dessous sont ceux que nous avons pu rattacher à une source primaire (postmortem de l'exploitant, commit du noyau, bug tracker) ou à une presse technique qui la cite.

Deux attributions reviennent souvent et sont fausses. Le gel des baladeurs Zune du 31 décembre 2008 est un bug d'année bissextile (le 366^e jour), pas de seconde intercalaire. Les pannes d'Instagram, Netflix et Pinterest du 29-30 juin 2012 viennent de l'orage qui a coupé un centre de données d'AWS en Virginie, le même week-end.

4. Comment NTP signale une seconde intercalaire (Leap Indicator)

Le protocole NTP (RFC 5905, §7.3) réserve les deux bits de poids fort du premier octet du paquet au champ Leap Indicator (LI). C'est un avertissement qui porte sur la dernière minute du mois en cours. Quatre valeurs possibles :

Le RFC 5905 ne fixe pas de préavis. Le RFC 8633 (§3.7) recommande aux serveurs d'attendre le dernier jour du mois pour annoncer ; c'est ce que fait le NIST, dont les serveurs annoncent à partir de 00:00 UTC ce jour-là. ntpd, lui, peut maintenir l'annonce pendant tout le dernier mois. Un serveur Stratum 1 tient l'information de sa référence (GNSS, DCF77) ou du fichier leap-seconds.list, que publie l'IERS et que redistribue la base tz de l'IANA. Le fichier porte une empreinte (#h) et une date d'expiration (#@) : la version en cours, mise à jour avec le Bulletin C 72, expire le 28 juin 2027.

5. Step vs smear : deux écoles

Quand 23:59:60 arrive, il faut choisir ce qui se passe côté système :

5.1 Approche step (insertion d'une seconde 23:59:60)

Conforme à la définition d'UTC : l'horloge vit une vraie minute à 61 secondes. Sous Linux, le noyau répète la dernière seconde ; c'est le comportement par défaut de chrony (leapsecmode system) et de ntpd. Le NIST procède de même : ses serveurs répètent 23:59:59. Avantage : l'horloge reste strictement alignée sur UTC. Inconvénient : deux secondes portent le même horodatage, et tout programme qui suppose un temps strictement croissant peut se tromper, comme l'ont montré les incidents ci-dessus.

5.2 Approche smear (étalement)

Imaginée par Google après la seconde de 2005, testée en 2008 et rendue publique en 2011 : plutôt qu'un saut d'une seconde, on modifie très légèrement la durée des secondes pendant plusieurs heures, jusqu'à avoir absorbé la seconde entière. Avec un étalement linéaire sur 24 heures, chaque seconde dure 1,0000115 s environ, soit 11,6 ppm. Avantage : aucun horodatage répété, aucun timer cassé. Inconvénient : pendant la fenêtre, l'heure servie n'est pas UTC. Un étalement centré sur l'événement s'en écarte jusqu'à une demi-seconde ; un étalement qui démarre après l'événement, comme celui de Meta ou de chrony, part d'un écart d'une seconde.

5.3 Qui fait quoi

Apple (time.apple.com) et les laboratoires nationaux comme la PTB ne publient pas leur politique ; nous ne leur en prêtons pas.

6. Savoir ce que font vos serveurs amont

La réponse courte est inconfortable : hors d'une fenêtre de seconde intercalaire, rien dans un paquet NTP ne dit si un serveur étale. Le RFC 8633 le constate : « there is no standardized way for a client to detect that a server is using leap smearing ». Un serveur qui étale n'annonce pas la seconde, et Google laisse le LI à 0 en permanence. Trois sources d'information restent disponibles.

1. La documentation de l'opérateur. Hors événement, vous n'aurez rien d'autre. Le tableau ci-dessus rassemble ce que les opérateurs publient ; pour les autres, l'absence de déclaration n'est pas une réponse.
2. Le LI pendant la période d'annonce. Le dernier jour du mois, un serveur conforme annonce la seconde ; un serveur qui étale reste à 0. Avec chrony, chronyc ntpdata donne le Leap status de chaque source, et chronyc tracking celui retenu par votre serveur (Normal, Insert second, Delete second). Avec ntpd, ntpq -c rv affiche leap=.
3. L'écart pendant la fenêtre. Comparé à une référence qui ne lisse pas, un serveur qui étale dérive progressivement jusqu'à plusieurs centaines de millisecondes. Si vous avez des sources conformes en nombre, c'est visible dans chronyc sources : la source qui étale passe en false ticker.

# Ce que votre serveur a retenu
chronyc tracking | grep 'Leap status'

# Ce que chaque source annonce (ici, une source nommée)
chronyc ntpdata time.cloudflare.com | grep 'Leap status'

# ntpd
ntpq -c rv | tr ',' '\n' | grep leap

chronyc smoothing ne sert pas à cela : il décrit le lissage du serveur local, pas celui de ses amonts.

7. chrony : leapsecmode, leapseclist, smoothtime

Deux questions distinctes, deux jeux de directives. leapsecmode décide de ce que le serveur fait de sa propre horloge. smoothtime décide de ce qu'il sert à ses clients. Le smearing n'est pas une valeur de leapsecmode.

# /etc/chrony/chrony.conf

# Horloge locale : déléguer au noyau Linux l'insertion de la seconde (défaut)
leapsecmode system
# Autres valeurs : step (chronyd fait le saut), slew (correction progressive,
# une douzaine de secondes avec le maxslewrate par défaut), ignore

# Source locale de l'information : la liste de l'IERS livrée par tzdata
leapseclist /usr/share/zoneinfo/leap-seconds.list

Le smearing se configure à côté. La documentation de chrony donne cette combinaison ; la première ligne est nécessaire, sinon le saut de l'horloge locale remettrait le lissage à zéro.

# Smear : étaler la seconde sur ce que le serveur SERT
leapsecmode slew
maxslewrate 1000
smoothtime 400 0.001024 leaponly

leaponly limite le lissage aux secondes intercalaires : les écarts et dérives ordinaires ne sont pas lissés. Avec smoothtime 400 0.001024, le lissage démarre à 00:00:00 UTC et dure environ 17 heures (62 500 secondes) : la fréquence monte jusqu'à 32 ppm puis redescend, et l'aire sous cette rampe vaut la seconde à rattraper. Pendant la fenêtre, le serveur ne transmet plus l'annonce, et l'heure qu'il sert part d'un écart d'une seconde avec UTC, qui décroît jusqu'à zéro.

La documentation de chrony réserve cette option aux réseaux locaux : les clients doivent n'avoir qu'un serveur qui lisse, ou plusieurs configurés à l'identique, et ne doivent eux-mêmes charger aucune liste de secondes intercalaires. Sur un serveur public, le RFC 8633 l'interdit.

8. ntpd : leapfile et annonce

ntpd (référence ou NTPsec) lit le même fichier leap-seconds.list et le revérifie une fois par jour :

# /etc/ntp.conf

# Liste de l'IERS, redistribuée par tzdata
leapfile /usr/share/zoneinfo/leap-seconds.list

Quand le fichier est présent, ntpd ignore les bits LI de ses sources et arme la seconde à moins d'un mois de l'échéance. Sans fichier, il suit la majorité de ses sources. Le fichier expire : si tzdata n'est pas tenu à jour par votre distribution, récupérez-le directement.

0 3 * * 1 wget -q -O /usr/share/zoneinfo/leap-seconds.list https://data.iana.org/time-zones/data/leap-seconds.list

ntpd dispose aussi d'une option de lissage, leapsmearinterval, expérimentale et compilée à part ; sa documentation prévient : « DO NOT USE THIS OPTION ON PUBLIC-ACCESS SERVERS! ».

9. Notre politique sur les serveurs RDEM

• Annonce. Nos serveurs transmettent le Leap Indicator à leurs clients. Un client qui nous suit reçoit l'annonce et applique la seconde lui-même.
• Source de l'information. Chaque serveur lit leap-seconds.list fournie par tzdata, et confronte ses sources Stratum 1 : laboratoires nationaux (Observatoire de Paris, PTB), Netnod, points d'échange selon les sites, et notre propre Stratum 1 GPS.
• Google parmi nos sources, en connaissance de cause. time.google.com figure parmi les 17 à 20 serveurs amont de chacune de nos machines, parce qu'il est fiable le reste du temps. Pendant une fenêtre de lissage, il s'écarterait progressivement des autres et la sélection de chrony l'écarterait comme false ticker : une source contre seize à dix-neuf. Il n'annonce jamais la seconde, mais cela ne peut pas la faire manquer : la liste locale suffit à l'armer, quel que soit le vote des sources.
• Seconde négative. chrony sait la traiter (Delete second), et nos serveurs l'appliqueraient comme une seconde positive. Personne ne l'a jamais vue en production : c'est précisément l'argument du vote d'octobre.
• Vos clients. Si vous voulez de l'heure lissée, lissez chez vous, sur un serveur local, et ne mélangez pas ce serveur avec les nôtres.

10. Préparer un événement

Tant que le mécanisme existe, maintenir la capacité à gérer une seconde intercalaire fait partie de l'hygiène NTP :

1. Vérifier la source locale sur chaque serveur : la directive (leapseclist ou leapfile) doit pointer vers un fichier qui existe, et grep '^#@' /usr/share/zoneinfo/leap-seconds.list doit donner une expiration dans le futur.
2. Tester sur un serveur de staging avec un fichier de liste portant une échéance proche : les logs doivent montrer l'annonce puis l'insertion.
3. Documenter la politique (step ou smear) pour chaque segment d'infrastructure, et savoir ce que font vos sources (section 6).
4. Auditer les applications critiques : toute logique qui fait if (new_ts == old_ts) ou assert ts_diff > 0 sur l'horloge murale doit passer sur une horloge monotone.
5. Planifier une fenêtre d'observation si un Bulletin C annonce un événement : il tombe six mois plus tard, le 30 juin ou le 31 décembre.

11. La fin de la seconde intercalaire : le vote du 15 octobre 2026

2022, le principe. La 27^e Conférence générale des poids et mesures (CGPM) a décidé, par sa résolution 4, que l'écart maximal UT1 − UTC serait augmenté « en 2035 ou avant ». Elle chargeait le Comité international (CIPM) de proposer à la conférence suivante une nouvelle valeur, qui assure la continuité d'UTC pendant au moins un siècle, et un calendrier. L'Union internationale des télécommunications a suivi en 2023 (CMR-23, résolution 655) : une tolérance d'au moins 100 secondes, une mise en œuvre « possiblement en 2035 ».

2026, la décision. La 28^e CGPM se réunit du 13 au 15 octobre 2026 au Palais des Congrès de Versailles. Le vote sur le projet de résolution C, « sur les actions techniques nécessaires pour assurer la continuité de l'UTC », est inscrit le jeudi 15 octobre, à 14 h 15. Chacun des 69 États membres de la Convention du Mètre dispose d'une voix. Le texte, dont seule la version française fait foi, décide que :

• « l'UTC continu entrera en vigueur le 20 mai 2027 » ;
• « la valeur maximale pour la différence |UT1-UTC| sera de 3 600 secondes (1 heure), ce qui assurera une continuité à long terme de l'UTC pendant plusieurs siècles ».

Le calendrier a été avancé de 2035 à 2027 à cause de la seconde négative. Le rapport du CCTF estime à environ 30 % la probabilité d'une seconde négative dans les dix ans, et à environ 50 % celle d'une seconde positive : « to avoid any risk, UTC should be made continuous by 2027 ».

Pour NTP, rien ne change dans le protocole : le Leap Indicator reste défini, et chrony comme ntpd garderont le mécanisme pour les archives et les systèmes qui ne seront pas migrés. Le fichier leap-seconds.list continuera d'exister, avec une dernière ligne qui ne bougera plus. Côté conformité, les réglementations qui imposent une traçabilité à UTC, comme le RTS 25 de MiFID II pour les plateformes de négociation, suivront la définition d'UTC que la CGPM aura votée.

Ressources et références

• IERS, Bulletin C — annonce, deux fois par an, d'une seconde intercalaire ou de son absence
• leap-seconds.list (IANA) — la liste de l'IERS, redistribuée par la base tz
• RFC 5905 — NTPv4, champ Leap Indicator (§7.3)
• RFC 8633 — bonnes pratiques NTP : annonce des secondes intercalaires et interdiction du lissage sur un serveur public (§3.7)
• Documentation de chrony.conf — leapsecmode, leapseclist, smoothtime
• CGPM 2022, résolution 4 — le principe d'un UTC continu
• CGPM 2026, projets de résolution — le projet C soumis au vote du 15 octobre 2026
• Fortius Intel, « Sixty-Eight Nations Vote in October on What a Second Means » (en anglais) — analyse des conséquences du vote pour les systèmes financiers soumis au RTS 25
• Interne — Propagation stratum 0 → 16 : contexte technique de la hiérarchie NTP