Seconde Intercalaire NTP : leap second, smear et retour d'expérience

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 le lent ralentissement 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 : 24 heures d'alerte, un plan de bascule, et des logs à scruter pendant les 48 heures suivantes.

Cette page couvre ce que tout opérateur ou administrateur NTP doit comprendre : l'origine du mécanisme, l'historique des 27 secondes intercalaires ajoutées depuis 1972, la façon dont NTP les signale, les deux approches concurrentes (step et smear), le comportement de chrony et ntpd, et l'échéance d'abolition votée en 2022.

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 Terre ralentit : frottement des marées, redistribution des masses internes, interactions noyau-manteau. Sur le long terme, UT1 prend du retard sur UTC d'environ 1 à 2 ms par jour en moyenne — une seconde accumulée tous les 12 à 24 mois.

L'IERS (International Earth Rotation Service) surveille cette dérive et, quand elle approche 0,9 seconde, publie un « Bulletin C » annonçant une seconde intercalaire six mois à l'avance. L'événement prend place au choix le 30 juin ou le 31 décembre à 23:59:59 UTC : la seconde 23:59:60 est insérée (très rare cas d'une minute à 61 secondes), puis 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, qui sont aussi celles vécues par l'infrastructure RDEM :

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 inattendue de la rotation terrestre.

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

Le protocole NTP (RFC 5905) réserve les deux bits de poids fort du premier octet du paquet au champ Leap Indicator (LI). Quatre valeurs possibles :

Quand un serveur Stratum 1 reçoit l'information (via son refclock GPS/DCF77, ou par fichier leap-seconds.list signé par le NIST), il commence à propager LI=01 dans ses réponses 24 heures avant l'échéance. Les clients chrony et ntpd lisent ce bit à chaque poll, et planifient l'insertion locale.

4. Step vs smear : deux écoles

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

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

Conforme à la norme : le noyau insère une vraie minute à 61 secondes. C'est le comportement par défaut de chrony et ntpd avec leapsecmode=system/step sur Linux. Avantage : l'horloge reste strictement alignée sur UTC. Inconvénient : deux timestamps identiques consécutifs, et toute application qui fait timespec.tv_sec - previous peut obtenir 0, ce qui casse les timers à base de secondes.

4.2 Approche smear (étalement)

Popularisée par Google en 2011 : plutôt qu'un saut d'une seconde, on ralentit l'horloge de quelques ppm sur une fenêtre de 20 à 24 heures autour de l'événement. Chaque tick dure 1.000011574 s au lieu de 1.0 s exactement — la seconde est absorbée progressivement. Avantage : aucun timestamp non monotone, aucun timer cassé. Inconvénient : pendant la fenêtre de smear, l'horloge est jusqu'à 0,5 seconde décalée d'UTC, ce qui peut être visible depuis une source externe non-smearée.

4.3 Qui fait quoi en 2026

5. chrony : leapsecmode, smoothtime, leapsectz

leapsecmode a quatre valeurs, et le smearing n'en fait pas partie — c'est une directive distincte, smoothtime, qui décrit ce que le serveur sert à ses clients, pendant que leapsecmode décrit ce qu'il fait de sa propre horloge. Confondre les deux, c'est ce que faisait cette page.

# /etc/chrony/chrony.conf

# Mode recommandé pour un serveur Stratum 2+ en production :
# déléguer au noyau Linux l'insertion de la seconde
leapsecmode system

# Alternative 1 : step d'une seconde appliqué par chronyd lui-même
# leapsecmode step

# Alternative 2 : correction progressive par slew
# leapsecmode slew

# Alternative 3 : aucune correction de l'horloge locale
# leapsecmode ignore

# Pour tester sans attendre le prochain événement : fichier de liste leap
leapsectz right/UTC
leapseclist /usr/share/zoneinfo/leap-seconds.list

Le smearing est autre chose, et se configure à côté. La documentation de chrony donne cette combinaison, et explique pourquoi la première ligne est nécessaire : sans elle, le step 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 événements leap : les écarts et dérives ordinaires ne sont pas lissés. Avec smoothtime 400 0.001024, la seconde est absorbée sur environ dix-sept heures : la fréquence monte jusqu'à 400 ppm puis redescend, et l'aire sous cette rampe vaut la seconde à rattraper. Pendant la fenêtre, l'horloge servie s'écarte progressivement d'UTC, au maximum d'une demi-seconde — c'est l'ordre de grandeur des fenêtres de 24 h employées par Google et AWS.

6. ntpd : leapfile, tinker step, kernel mode

ntpd (référence ou ntpsec) lit le fichier leap-seconds.list maintenu par le NIST :

# /etc/ntp.conf

# Fichier de référence signé, mis à jour par l'IERS/NIST
leapfile /usr/share/zoneinfo/leap-seconds.list

# Comportement par défaut : step d'une seconde conforme
# Désactiver si besoin avec :
# tinker step 0

# Pour bénéficier du mode noyau Linux sur sync :
# enable kernel

Le fichier leap-seconds.list doit être mis à jour régulièrement — il expire 6 mois après son émission. Automatisez via cron :

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

7. Ce que RDEM a observé depuis 2005

• La veille : nos serveurs Stratum 1 commencent à annoncer LI=01 à 00:00:00 UTC (24 heures avant). C'est le moment d'éviter les déploiements importants. Les clients bien configurés propagent ensuite l'annonce en cascade.
• L'instant T : à 23:59:60 UTC, les Stratum 1 insèrent la seconde via leur noyau. Les Stratum 2 qui les suivent l'appliquent dans les secondes qui suivent, avec un offset transitoire mesurable sur 30 à 120 secondes.
• Les 24 h suivantes : les logs remontent quelques faux positifs « clock stepped » sur des clients mal synchronisés. Les applications les plus fragiles à surveiller ont toujours été les bases de données (corruption d'index temporel rare mais documentée chez PostgreSQL pre-9.6 et MySQL pre-5.6) et les tâches cron à cadence seconde.
• Les clients IoT : systématiquement les moins propres. Une partie des appareils grand public ignorent LI et se resynchronisent brutalement après coup — le fameux saut visible d'une seconde dans le rendu d'une horloge Wi-Fi le 1^er janvier au matin.
• Le tooling : chronyc tracking et ntpq -c rv restent les seules commandes indispensables pendant l'événement. Guardez un terminal ouvert dessus entre 23:59:00 et 00:02:00 UTC.

L'événement 2016-12-31 est celui qui nous a le plus marqué : c'est le dernier à date et celui où les outils grand public (smartphones, box internet) avaient le mieux convergé vers un comportement correct. L'écosystème est plus mûr qu'en 2005 ou 2008, où nous devions encore expliquer à des clients ce qu'était LI=01 dans leurs logs.

8. Préparer le prochain événement

Même sans annonce à l'horizon, maintenir la capacité à gérer un leap second fait partie de l'hygiène NTP :

1. Vérifier le fichier leap-seconds.list sur chaque serveur : head /usr/share/zoneinfo/leap-seconds.list doit montrer une date d'expiration dans le futur.
2. Tester le mode leap sur un serveur de staging en injectant manuellement un fichier leap avec une date proche : les logs doivent montrer l'anticipation correcte.
3. Documenter la politique (step ou smear) pour chaque segment d'infrastructure, et s'assurer qu'un même client ne mélange pas les deux en amont.
4. Auditer les applications critiques : toute logique qui fait if (new_ts == old_ts) ou assert ts_diff > 0 doit être revue.
5. Planifier une fenêtre d'observation autour de la date annoncée si un événement est déclenché. La probabilité actuelle d'un leap second d'ici 2035 reste faible mais non nulle.

9. L'abolition de 2035 : quoi anticiper

En novembre 2022, la 27^e Conférence Générale des Poids et Mesures (CGPM) a voté la résolution qui abolit la seconde intercalaire d'ici 2035. Le texte prévoit :

• Maintenir le mécanisme jusqu'en 2035 au plus tard.
• Élargir la tolérance UTC − UT1 actuelle (0,9 s) à une valeur significativement plus grande (non encore fixée — 100 s est évoqué, qui donnerait un événement d'ajustement tous les 100 à 200 ans).
• Laisser le temps aux opérateurs de télécommunications, de navigation satellitaire et de finance de migrer leurs chaînes.

Pour NTP, cela ne change rien au protocole — le champ Leap Indicator reste en place pour les archives et les systèmes legacy. Simplement, son activation deviendra exceptionnelle puis nulle. Les implémentations chrony et ntpd continueront à supporter le mécanisme pour des raisons de compatibilité pendant plusieurs décennies.

Ressources et références

• IERS Bulletin C — annonces officielles d'insertion ou non
• leap-seconds.list (IANA) — fichier à jour
• RFC 8633 — NTP Best Current Practices, gestion des leap seconds §3.2
• RFC 5905 — NTPv4, champ Leap Indicator §7.3
• CGPM 2022 Résolution 4 — décision d'abolition
• Interne — Propagation stratum 0 → 16 : contexte technique de la hiérarchie NTP