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.