Quelques documentations pour comprendre comment les secondes intercalaires peuvent être digérées par nos systèmes informatiques :
Voici un gros résumé.
La méthode POSIX standard, c'est d'incrémenter le temps, de revenir en arrière d'une seconde et de continuer à incrémenter. On rejoue donc une même seconde. C'est la méthode « step back ». Cette méthode peut être mise en œuvre par le noyau ou par le démon NTP (disable kernel
avec ntpd). La deuxième méthode permet de se prémunir d'un bug dans le noyau et de maintenir à l'heure un système dont le noyau ne propose pas d'API pour lui indiquer l'imminence de la seconde intercalaire. Linux dispose d'un bout de code permettant le traitement des secondes intercalaires. L'ennui avec la méthode step back dans son ensemble, c'est que le temps revient en arrière, il n'est plus continu. Cela peut mettre la grouille sur les systèmes qui dépendent fortement de l'ordre des événements pour fonctionner comme les gestionnaires de bases de données ou les clusters de stockage distribués (lors de la seconde intercalaire de 2005, Google a constaté que certains de ses serveurs de stockage étaient out).
La méthode NTP standard, en interne des implémentations des serveurs NTP est de stopper/maintenir le temps durant la seconde intercalaire. C'est la méthode « hold ». Ainsi, le temps reste continu. Voir : https://www.eecis.udel.edu/~mills/leap.html
Une autre méthode est d'augmenter très progressivement le temps pour compenser la seconde intercalaire.
On peut aussi choisir d'ignorer la seconde intercalaire et de la traiter après coup comme un problème standard de dérive du temps.
Évidemment, chaque façon de faire a ses avantages et inconvénients en fonction des usages :
Perso, je retiens que le comportement par défaut, step back, suffit pour mes usages. Si besoin que le temps s'écoule de manière continue, utiliser les méthodes « slew » ou, si la dérive de l'horloge n'est pas un problème, ignorer la seconde intercalaire.
Notons que les paquets NTP disposent d'un drapeau « Leap Indicator » qui permet d'indiquer la seconde intercalaire durant les 24 heures précédant son application. Ce flag, qui est positionné par le serveur de strate 1 (celui directement raccordé à un appareil de mesure du temps genre GPS ou horloge atomique) ou par n'importe quel serveur de n'importe quelle strate, se transmet de serveurs NTP en serveur NTP et permet aux clients et serveurs NTP d'informer le noyau de l'imminence d'une seconde intercalaire. Le noyau stocke l'information et fera le changement à l'heure convenue universellement (23h59m59 UTC). Un reboot de la machine nécessite d'informer à nouveau le noyau, bien évidemment.
Comment un serveur de temps positionne-t-il le flag LI ? Soit parce que sa référence de temps le lui a appris, soit parce qu'il utilise un fichier publié par le NIST qui contient les secondes intercalaires passées et celles à venir, voir : http://support.ntp.org/bin/view/Support/ConfiguringNTP#Section_6.14 . Il faut évidemment garder ce fichier à jour (2 fois par an max).
Regardons ce flag avec tshark :
Network Time Protocol (NTP Version 4, server)
Flags: 0x64
01.. .... = Leap Indicator: last minute of the day has 61 seconds (1)
..10 0... = Version number: NTP Version 4 (4)
.... .100 = Mode: server (4)
Peer Clock Stratum: secondary reference (2)
Peer Polling Interval: invalid (3)
Peer Clock Precision: 0,000000 sec
Root Delay: 0,0076 sec
Root Dispersion: 0,0387 sec
Reference ID: 145.238.203.14
Reference Timestamp: Dec 31, 2016 12:46:39.884128000 UTC
Origin Timestamp: Dec 31, 2016 13:02:54.234703000 UTC
Receive Timestamp: Dec 31, 2016 13:02:54.341816000 UTC
Transmit Timestamp: Dec 31, 2016 13:02:54.341864000 UTC
En temps normal :
Network Time Protocol (NTP Version 4, server)
Flags: 0x24
00.. .... = Leap Indicator: no warning (0)
..10 0... = Version number: NTP Version 4 (4)
.... .100 = Mode: server (4)
Peer Clock Stratum: secondary reference (2)
Peer Polling Interval: invalid (3)
Peer Clock Precision: 0,000000 sec
Root Delay: 0,0076 sec
Root Dispersion: 0,0500 sec
Reference ID: 145.238.203.14
Reference Timestamp: Apr 2, 2017 10:13:49.572752000 UTC
Origin Timestamp: Apr 2, 2017 10:26:29.182950000 UTC
Receive Timestamp: Apr 2, 2017 10:26:29.350805000 UTC
Transmit Timestamp: Apr 2, 2017 10:26:29.350865000 UTC
Note "fun" : encore en 2017, il semblerait que des bugs surviennent dans le traitement informatique de la seconde intercalaire. « Amazingly there are also 4 servers that are off by a second in the wrong direction (like they applied the leap second twice). ». Source : https://community.ntppool.org/t/leap-second-2017-status/59 .