La grande panne de nombreux serveurs Linux
le 1er juillet a remis sur le tapis la question des
secondes intercalaires. S'il y a toujours des
bogues aussi sérieuses dans le code qui les gère, ne faudrait-il pas
supprimer le problème en simplifiant l'échelle de temps
UTC, par la suppression de ces secondes
intercalaires ?
D'abord, il faut établir clairement les responsabilités : ce
comportement anormal de Linux (le meilleur
article technique est celui
de ServerFault, très détaillé) est une
bogue. Quarante ans après
la création des secondes
intercalaires, il est anormal qu'il reste encore de telles
bogues dans un programme répandu, alors qu'il y a déjà eu 25 secondes
intercalaires, donc plein d'occasions de tester.
Ensuite, le problème n'est pas dans UTC ou
dans les secondes
intercalaires. Le problème est dans la
Terre qui ne « tourne pas rond ». Son mouvement
n'est pas constant et, pire, il n'est pas prédictible. Lorsque
certains articles anti-secondes-intercalaires ont écrit « il n'est pas
normal qu'on ne puisse pas calculer le temps à l'avance », ils disent
une grosse bêtise. Normal ou pas, c'est ainsi que le monde réel
fonctionne.
Comme on ne peut pas
« patcher » la Terre, que
reste-t-il comme solutions ? Les adversaires de la seconde
intercalaire proposent de supprimer cette dernière
d'UTC. Mais je trouve cette « solution » tout à
fait inutile. Il existe déjà une échelle de temps sans secondes
intercalaires et c'est TAI ! Supprimer les
secondes intercalaires revient à aligner UTC sur TAI, faisant perdre
l'intérêt qu'il y a à avoir deux échelles :
TAI (qui est complètement indépendant des astres) est pratique pour les informaticiens, notamment parce que son déroulement est
prévisible.UTC est pratique pour les gens qui mettent le nez dehors, car
elle garantit que l'heure reste proche de celle des astres (le
Soleil au plus haut à midi, ce genre de
choses).
Les deux ont leur légitimité et leur utilité. Les gens qui réclament
la suppression des secondes intercalaires pour simplifier les
programmes n'ont tout simplement pas compris cela. (TAI a actuellement
35 secondes de
décalage avec UTC, si bien qu'on ne voit pas encore de conséquences pratiques.)
Mais, me dira-t-on, UTC, avec ses secondes intercalaires, est bien
compliqué pour des programmes qui souhaitent avoir une horloge
monotone et prévisible (comme les bases de données réparties, les grandes victimes de la panne). Dans ce cas, la solution est d'utiliser
TAI. Hélas, sur Unix, la situation est
compliquée. Il n'y a pas de moyen simple d'accéder à TAI. Quelques
solutions possibles :
Posix a une option CLOCK_MONOTONIC
(voir la
définition de clock_gettime()) qui n'est pas vraiment TAI et ne
semble pas beaucoup mise en œuvre.On peut aussi modifier le système pour ne pas appliquer la
seconde intercalaire d'un coup, comme
l'a fait Google qui avait besoin d'un temps monotoniquement
croissant pour ses serveurs,Attendre qu'un patch permettant l'accès à TAI (comme celui de
Richard Cochran) soit intégré dans Unix,Utiliser une bibliothèque comme libtai. Attention, comme elle
marche en accédant à UTC (la seule information disponible sur Unix) et
en corrigeant, elle dépend de listes de secondes intercalaires à jour,
ce qui n'est pas le cas de la distribution officielle (alors que l'IANA) distribue cette information, dans le fichier leapseconds, et qu'elle est correcte ; pourquoi diable libtai ne l'utilise pas ?).Sur le même principe (corriger puisqu'on connait le décalage
entre TAI et UTC), un simple fichier timezone
d'Alain Thivillon, bien plus simple à utiliser et très efficace.
Alain a aussi produit un script simple pour fabriquer une table des décalages
UTC-TAI à partir du registre des temps à
l'IANA. Voici comment on peut
l'utiliser. D'abord, exécuter de temps en temps (pour mettre à jour le
fichier), par exemple depuis cron :
% cd /usr/share/zoneinfo
% perl /usr/local/sbin/gentai.pl
Zonefile ./tai generated
Zonefile ./tai compiled in Etc/TAI
You can check with "TZDIR=/usr/share/zoneinfo TZ=Etc/TAI date && TZ=UTC date"
Leapsecond file ./leapseconds_iana saved
Ensuite, lorsque vous avez envie de voir le temps TAI, vous définissez
juste la variable d'environnement qui va bien :
% TZ=Etc/TAI date && date -u
Fri Jul 6 21:00:16 TAI 2012
Fri Jul 6 20:59:41 UTC 2012
Vous voyez bien les trente-cinq secondes de décalage actuels.
À noter que cette idée d'avoir deux échelles, TAI et UTC, qui
reconnait le fait qu'il y a deux populations d'utilisateurs, avec des
besoins différents, est rejetée par le BIPM qui
considère que deux,
c'est trop, à cause du risque de confusion.
Autres lectures :
Le bulletin C annonçant cette seconde intercalaire,Le débat sur la
suppression de la seconde intercalaire et ma position,Une intéressante proposition
alternative de réforme d'UTC, faisant varier l'horloge progressivement
(comme dans la solution de Google) et non pas d'un coup,Un bon
article expliquant la gestion de la seconde intercalaire par NTP,Une proposition
concrète de Steve Allen pour résoudre ce dilemme (attention,
c'est technique).Pour les Unixiens, un bon
article sur le temps dans Unix, même UTC est mal géré (avec retour de l'horloge en arrière),Une vigoureuse
critique de la gestion du temps dans Unix,Une autre,
uniquement pour ceux qui supportent le ton de
D. J. Bernstein.Sur les conséquences de la bogue Linux, l'article
de Wired.
Remerciements à Steve Allen, Tony
Finch, Pierre
Beyssac, Alain
Thivillon et Peter van
Dijk pour la discussion sur TAI dans Unix. Merci à Kim-Minh
Kaplan pour le rappel qu'UTC ne va jamais en arrière, c'est Unix (ou
d'autres systèmes) qui le fait, ne sachant pas gérer la seconde
intercalaire.