Message non lu
par El Fredo » 04 juil. 2012, 09:49:45
La gestion du temps est un problème essentiel et très complexe en informatique, notamment distribuée (et l'Internet est un réseau massivement distribué). Sans mesure précise de temps, pas de GPS par exemple. Une seconde reste une seconde quoi qu'il arrive, donc pas de souci côté étalonnage, seconde intercalaire ou pas. Mais le problème est que la rotation de la Terre varie de façon aléatoire et imprévisible (les tremblements de terre et les mouvements tectoniques lui font faire des "sauts"). Donc c'est la définition de l'heure et pas du temps qui pose problème, car l'heure est une donnée relative basée sur un référentiel. Dans le monde entier on utilise le système UTC (Universal Time Code), parfois appelé à tort le GMT (Greenwich Mean Time, autrement dit l'heure du méridien de l'observatoire de Greenwich), et de nombreux pays s'en servent comme base légale donc ce n'est pas un problème uniquement technique mais également juridique. Imaginez ce que ça peut donner comme litige en cas d’évènement survenant le 31 décembre à 23:59:59. Sans compter les forces armées et l'aviation civile qui se synchronisent à la seconde près (le "Zulu Time").
Le problème des secondes intercalaires est loin d'être trivial, et on ne peut malheureusement pas les abolir au risque de voir les horloges se décaler avec le temps, un peu comme avant l'introduction des années bissextiles (qui elles sont parfaitement prévisibles). Ainsi le "midi solaire" dans 500 ans pourrait être décalé d'une heure.
Pour comprendre la cause des problèmes rencontrés par les systèmes informatiques, il suffit d'imaginer deux systèmes communiquant au moment où les secondes intercalaires sont introduites. Si l'un applique cette correction et pas l'autre, ils peuvent se retrouver à recevoir des messages du futur et les rejeter ou alors carrément planter : la différence de date donne un nombre négatif, qui peut être interprété comme un nombre non signé très élevé. Par exemple dans le système de représentation binaire dit "complément à deux" utilisé par quasiment tous les systèmes informatiques, la valeur signée -1 a la même représentation que la valeur non signée 4294967295 sur les systèmes 32-bits, et 18446744073709551615 sur les systèmes 64-bits. Imaginons qu'on utilise des entiers pour compter les millisecondes entre chaque message. Préalablement à la communication les deux systèmes ont synchronisé leurs horloges (un domaine de recherche à lui tout seul). Ensuite les deux systèmes s'échangent des messages toutes les secondes environ, donc la différence de "timestamp" est d'environ 1000, et cette valeur est utilisée comme temporisation pour les prochains messages (technique courante dans les communications temps réel synchronisées type conférence audio ou vidéo). Survient alors une "leap second", les horloges des deux systèmes se décalent brusquement. La différence de timestamps passe alors à zéro environ, ce qui peut donner des valeurs négatives. Si l'un des systèmes reçoit un message daté de 1 milliseconde dans le futur, il se retrouve avec une différence de timestamp égale à -1. En non signé ça donne donc 4294967295 millisecondes soit 49 jours ! Imaginez que votre système attende 49 jours avant de répondre au message ! Et c'est encore pire en 64-bit, de plus en plus répandu sur les serveurs : 18446744073709551615 millisecondes donnent 584 millions d'années. Evidemment les administrateurs se seront aperçu du problème bien avant ça et auront réinitialisé les systèmes, mais vous pouvez facilement aboutir à une interruption de service de quelques heures ou plus.
Histoire de limiter les problèmes et d'avoir plus de temps pour s'y préparer, certains proposent donc de remplacer les secondes intercalaires par des heures, vu que décaler l'horloge d'une heure est un problème connu et facile à gérer (on le fait 2 fois par an pour les heures d'été et d'hiver). En effet l'introduction de secondes intercalaires creuse des "trous" dans les séquences de temps (et c'est ça qui pose problème comme ci-dessus), contrairement aux heures intercalaires qui consistent essentiellement à appliquer une correction de zonage a posteriori, les applications se contentent donc en général de gérer l'heure universelle et pas l'heure locale (d'autant plus que tous les pays n'ont pas la même réglementation en matière de corrections saisonnières). Ainsi des applications basées sur l'UTC n'auraient plus à se soucier des "leap seconds", seul le système aurait à gérer les "leap hours" pour l'affichage de l'heure locale.
If the radiance of a thousand suns were to burst into the sky, that would be like the splendor of the Mighty One— I am become Death, the shatterer of Worlds.
