Oui : la messagerie électronique est déjà prête à passer l'an 10000.
Depuis RFC 2822 "Internet Message Format", confirmé par sa mise à jour RFC 5322 en octobre 2008, la codification de l'année du champ "Date: " n'est pas limitée à quatre chiffres. Ainsi, après l'an 9999, nous ne verrons pas arriver l'an 0 mais bien l'an 10000. La prévention du bug de l'an 10000 est même explicitement mentionnée dans l'appendice B : "Four or more digits allowed for year."
Du moins, dans la messagerie électronique.
Pour rappel, ce RFC décrit le format des messages électroniques, sans s'intéresser au contenu (MIME), ni au protocole d'échange entre serveurs intermédiaires (SMTP), pas plus que le POP ou l'IMAP. Ce RFC décrit donc notamment les conventions relatives aux en-têtes ("From: ", "Date: ", "User-Agent: ", "Message-ID: ", etc).
La publication de RFC 5322 en octobre dernier s'est accompagnée de la publication de RFC 5321 (mettant à jour RFC 2821) sur le SMTP.
Par contre, qu'en sera-t-il du bug de l'an 2038, beaucoup plus proche de nous ?
Pour rappel, ce bug vient du codage sur un entier signé de 32 bits dans les architectures actuelles. Un rapide calcul :
$ echo "231/(3600*24*365) + 1970" | bc
2038
nous montre que la limite approche de l'an 2038. Le calcul exact montre que la date fatidique est le 19 janvier 2038 à 03:14:07 UTC.
Lorsque l'on voit les bugs des little et big-endian aujourd'hui, les integer overflows, et autres bugs intimement liés aux architectures matérielles, qu'en est-il des nombreuses applications critiques, très anciennes, métier ou middleware, SAP ou mainframes, que l'on rencontre régulièrement dans les infrastructures à haute disponibilité ? Nous espérons tous ne pas attendre 2038 pour découvrir la réponse.
Source : La Newsletter HSC est éditée par Hervé Schauer Consultants
Continuer avec Linkedin