Suite de la première partie
Comment fait-on pour horodater un message ? En informatique, les données sont représentées par des 0 ou des 1 ; c’est ce que l’on appelle un bit. Ces bits sont transmis par groupes de huit : les octets. Chaque bit pouvant prendre deux valeurs différentes, un octet peut prendre 28=256 valeurs différentes. Il est ainsi possible de transmettre l’heure sur six octets, en utilisant par exemple ce système très simple :
On met chaque composante de l’heure sur un octet et on obtient la date du 1er juin 2009, 11h 42m 12s d’une manière aisée. Le premier octet, l’année, se lit par exemple 9 car c’est 20+23=1+8=9 (les bits 0 et 3 sont les seuls valant 1 dans l’octet représentant l’année).
Il est assurément possible de gérer des centièmes de seconde en codant cette information sur un octet supplémentaire. L’heure du train pourrait en conséquence être déterminée par un équipement dit « maître » qui indiquerait l’heure à tous les équipements du train et qui se synchroniserait lui-même de manière automatique avec le sol, en utilisant par exemple le protocole NTP. Mais ce serait sans compter que de multiples problèmes peuvent survenir, comme l’impossibilité d’acquérir l’heure au réveil du train ou l’indisponibilité de certaines liaisons. D’où le fait qu’il soit nécessaire de pouvoir gérer l’heure localement au sein de chaque équipement du réseau, au même titre que ce que font nos propres ordinateurs personnels ; si l’heure peut être synchronisée, eh bien, à la bonne heure ! Sinon, tant pis, on fait de son mieux en essayant de ne pas trop dériver.
Nous ne sommes cependant pas au bout de nos peines -- même s’il arrivait que chaque équipement fût à la même heure – car lorsqu’ils communiquent, ils ne suivent pas forcément le système simple présenté précédemment… Pour donner une idée de la complexité de la chose, nous allons détailler un exemple sournois : le format dosdate/dostime. Celui-ci permet d’utiliser moins de place en compactant au maximum les informations transmises. Il est en effet manifeste que l’on « gaspille » des bits en codant le mois sur un octet complet (donc pouvant comporter 256 valeurs différentes alors que 12 valeurs suffisent, c’est-à-dire la moitié d’un octet puisque 4 bits permettent de représenter 24=16 valeurs distinctes).
Le 1er juin 2009, 11h 42m 12s peut donc être représenté de manière synthétique sous la forme suivante en utilisant seulement quatre octets :
Pas de répit ! Tic tac tic tac tic tac… Les 0 et les 1 s’entremêlent ! Cette représentation est connue sous le nom de « format de date DOS ». Certains équipements, assurément minoritaires, le gèrent nativement et c’est pourquoi il est parfois utilisé. L’information est condensée sur un mot de 4 octets (bits 0 à 7, 8 à 15, 16 à 23 et 24 à 31). La datation est précise à deux secondes près puisque seules les secondes paires sont comptées dans cette représentation (5 bits, pouvant donc coder une valeur comprise entre 0 et 31). Le nombre d’années est comptabilisé à partir de l’an de grâce 1980… Nous avons donc la valeur 29 en 2009 !
Lorsque ce format de date est décodé par un équipement, c’est octet par octet, ce qui donne dans notre exemple les valeurs décimales 58, 193, 93 puis 70 ! (58=21+23+24+25=2+8+16+32 pour le premier octet puisque les bits ici notés 25, 27, 28 et 29 de ce mot de 32 bits valent 1.)
De subtiles variantes à ce format existent : certains équipements ajoutent un bit pour gérer les secondes de manière complète, et utilisent en conséquence un bit en moins pour l’année (celle-ci est alors usuellement considérée à partir de l’an 2000, et peut donc aller jusqu’à 2063).
Et ce n’est pas tout ! Voici à titre informatif une liste non exhaustive de pièges qui peuvent faire passer de mauvais quarts d’heure aux informaticiens, intégrateurs et mainteneurs :
• la gestion de l’an 2064 (ou 2100, voire 2108 suivant les équipements et les formats de date) ;
• d’autres systèmes de datation totalement différents,
comme le format d’heure Unix
qui utilise le nombre de secondes écoulées depuis le 1er janvier 1970 minuit, voire même un autre calendrier ;
• la gestion des décalages horaires : est-ce l’heure universelle (UTC) ou l’heure de Paris ?
• la vérification de la cohérence de la date (un 29 février d’une année non bissextile
, un 31 avril, un treizième mois, une trentième heure, etc.) ;
• la gestion des secondes intercalaires ;
• la gestion des octets significatifs : par exemple, au lieu d’utiliser 6 pour le mois (00000110), certaines
implémentations forcent le bit de poids fort (le septième) à 1, ce qui donne 134 (10000110), ou encore forcent
à 1 tous les bits non significatifs, d’où 246 (11110110) pour le mois qui ne peut utiliser que 4 bits au maximum ;
• la gestion de tables de correspondance : par exemple associer à la valeur 3 le mois de mars car certaines
implémentations commencent la numérotation à 0 (pour avoir une cohérence avec l’année, l’heure, la minute et la
seconde), ce qui fait que 3 est le mois d’avril pour elles ;
• l’ordre des octets, non seulement lorsqu’ils sont séparés (2009/06/01 doit bien être décodé comme le 1er juin et
non comme le 6 janvier) mais aussi lorsqu’ils forment des mots sur plusieurs octets, comme le dosdate (certains
équipements sont nativement petits-boutistes et écriront 58,
193, 93 puis 70, contrairement aux gros-boutistes qui écriront dans l’ordre inverse les octets,
à savoir 70, 93, 193 puis 58) ;
• etc.