(Caveat : Merci de débrancher la prise de terre de votre cerveau avant de lire ceci.)

D’une part le Bug de l’An 2000 a traumatisé certains personnes. D’autre part certains scientifiques probablement optimistes (mais allez savoir...) estiment qu’une espérance de vie de mille ans sera très vite à notre portée (je ne retrouve plus l’article) - et pourquoi pas plus ?

Quitte à rêver, supposons que bientôt la technologie nous permette de nous déplacer dans des nefs spatiales se déplaçant à la vitesse de la lumière entre les étoiles. Les habitants des nefs ne vieilliraient biologiquement que de quelques dizaines/centaines d’années, mais, contraction temporelle des vitesses relativistes aidant, des millénaires et plus pourraient s’écouler pendant le voyage sur Terre et ailleurs. Ceci en supposant bien sûr que la numérisation de nos cerveaux ne nous accorde pas une quasi-immortalité[1].

Vue l’inertie et la masse de logiciels à adapter, la prise en compte d’années très lointaines en informatique doit donc commencer tout de suite !

La RFC2550 : Y10K and beyond résout déjà le problème. (Rappelons que les RFC définissent le comportement des logiciels devant communiquer avec d’autres, notamment les protocoles Internet.) Elle date du 1er avril 1999.

Je cite :

“Y10K compliant programs MAY choose to limit the range of dates they support to those consistent with the expected life of the universe.
Y10K compliant systems MUST accept Y10K dates from 10 ** 12 years in the past to 10 ** 20 years into the future.
Y10K compliant systems SHOULD accept dates for at least 10 ** 29 years in the past and future.”

« Les systèmes compatibles An 10000 ONT LE DROIT de choisir de limiter leur espace aux dates compatibles avec la durée d’existence supposée de l’univers.
Ces systèmes DEVRAIENT accepter au moins les dates 10 ** 29 années dans le passé et le futur. »

Existant

La RFC s’étend sur les systèmes informatique de comptage du temps déjà utilisés (décompte en secondes depuis 1970 pour Unix, valable jusque 2038 ; années sur deux chiffres insuffisantes comme démontré en 2000 ; années sur 4 chiffres ne fonctionnant pas après l’an 9999 ; années codées sur 16 bits non utilisables au-delà de 65 535...) et recherche d’autres possibilités.

  • Coder l’année sur cinq chiffres est un pis-aller qui permettra de dépasser le bug Y10K, mais posera problème en l’an 100 000 : une civilisation qui se met en tête de conquérir notre galaxie rencontrera le Bug avant la fin de son exploration (du moins dans le cadre des lois connues de la physique, qui interdisent un voyage à une vitesse supérieure à celle de la lumière).
  • Des années sur six chiffres codées sur 32 bits produiraient un bug de l’an 214 749. À peine suffisant pour un aller-retour d’un bout à l’autre de la Galaxie. Mais le 128 bits deviendra vite une option raisonnable qui permettra de compter jusqu’aux environs de 17.1033[2] - de quoi voir venir.
  • Cependant il y a aussi le problème de la granulométrie. À quoi bon stocker les années si on n’a pas accès aux millisecondes ? Nous ignorons la précision que les voyages interstellaires/temporels exigeront ; aussi la RFC, dans un premier temps, descend prudemment jusqu’à la femtoseconde (10-15 secondes).
    Malheureusement, un format de date de la forme YYY...YYMMDDHHMMSSmmmuuunnnpppfff (notation américaine) ne permet de compter que jusque 17 billions d’années dans le futur avec 128 bits.[3]
  • De plus, on peut prévoir que la femtoseconde devrait être la durée entre deux cycles d’un Pentium® MMDCLXVI de l’an 10 000, aussi cette précision sera-t-elle vite insuffisante également. (Le calcul date de 1999, et même si l’envolée des gigahertz s’est notablement ralentie récemment, le problème se posera tôt ou tard, en 20 000, 100 000 ou après ; de plus la multiplication des processeurs dans une même machine, que l’on constate déjà, rendra les impératifs de synchronisation parfaite d’autant plus sensibles.)
  • La RFC en déduit l’inadéquation de toute représentation sur un format fixe du type YY...YYMMDD.... Une représentation en virgule flottante pose de nombreux problèmes classiques (arrondis...)[4].

Descriptions des besoins

Les solutions simplistes ayant échoué, posons le problème plus posément :

  • L’informatique et les délais de migration étant ce qu’ils sont, une compatibilité avec les anciens format de date avec année sur quatre chiffres est impérative.
  • L’ordre de grandeur de la date doit être reconnaissable très rapidement.
  • L’ordre de tri des chaînes de caractères résultantes doit suivre l’ordre chronologique (par exemple, 20070108 suit 20061231 dans le temps comme dans l’ordre de tri, au contraire de 31122006, 14102005 et 220119999 qu’on ne peut trier sans connaître et décortiquer leur format).
  • Le format adopté au-delà de l’an 10 000 doit être généralisable, compatible et aisément triable avec d’autres formats, même de précision supérieure.
  • L’âge de l’Univers est estimé au grand maximum à 20 milliards d’années, et son espérance de vie à 1011 à 1014 années selon que notre destin à long terme soit scellé par le Big Crunch ou la mort thermique. Même s’il y échappe, l’âge de l’univers est supposé rester un nombre fini.
    Cette incertitude sur la Fin explique que la RFC spécifie que les logiciels peuvent se limiter à la prise en compte de dates dans cette fourchette.

La syntaxe

On adopte une syntaxe en texte simple (ASCII) de la forme déjà énoncée ci-dessus, commençant impérativement par YYYYY après 10 000, et utilisant autant de niveaux de précision que désiré de la forme MMDDHHMMSSmmmuuunnnpppfff... (précision décroissante vers la droite).

Le problème vient que le nombre de chiffres de l’années peut lui aussi être variable selon que l’on dépasse 10 000, 100 000, 1 000 000... Il faut donc stocker l’ordre de grandeur du nombre dans la notation.

  • Les années pré-10 000 doivent simplement se voir amendée d’un zéro préalable (02006 pour notre année).
  • Les années d’après 10 000 commencent par un A précédant le chiffre de l’année (A10000...A99999).
    En ASCII, le A suit le 9, donc ces années seront placées dans l’ordre lexicographique après les années 0...9999.
  • Le système s’étend aisément jusqu’à l’année 999 999 999 999 999 999 999 999 999 999 (notée Z999999999999999999999999999999), proche de 1030, ce qui explique que la RFC considère que les développeurs pourraient faire un peu d’effort pour implémenter la gestion des dates au moins jusque là (should).

L’aspect pratique est évident : pour comparer l’ordre de grandeur de H100000000000, I1000000000000 et K100000000000000, il suffit de comparer le premier caractère ; il est inutile de compter les chiffres. Les historiens de l’an 100 000 000 000 auront déjà assez de travail pour résumer la masse formidable de données à leur disposition.

Au-delà de 1030

Les progrès de la technologie éviteront peut-être la fin de l’Univers vers 1014, et l’année 1030 sera atteinte et dépassée. La notation doit être étendue si l’on veut faire un travail propre et définitif.

Une option naïve est de rajouter un symbole postérieur (au sens ASCII du terme) à Z, par exemple ^ : l’an 1056 est noté ^^A100000000000000000000000000000000000000000000000000000000. Deux circonflexes suffisent jusque 10732, trois jusque 1018 308.

En généralisant, on tombe sur un algorithme à base de suite de Fibonacci sur le nombre de ^ précédant les numéros d’années ; cette représentation est compacte.

Années avant Jésus-Christ

Pour maintenir l’ordre lexicographique, il est nécessaire de prendre le « complément Y10K » de l’année et d’ajouter quelques conventions de nommage décrites dans la RFC, qu’il me serait trop fastidieux de répéter ici.
La dernière année avant Jésus-Christ se note donc /9998, 9999 av. J.-C. est /0000, qui était précédée de *Z89999.

Points problématiques

  • La comparaison de dates de divers calendriers (maya, hittite, khmer...) n’est toujours pas possible.
  • Ce système ne prend pas en compte une éventuelle (et probable sur le très long terme) réinitialisation du calendrier avec un nouvel an zéro (Remarque : Notre calendrier a été mis en place avant l’arrivée du zéro en Occident, il n’y avait donc pas équivoque ; mais une nouvelle ère commencerait-elle par l’An Zéro ou l’An Un ?).
  • La destruction du système solaire dans les prochains milliards d’années va compromettre la pertinence d’un décompte en jours et années terriennes. (J’ajoute personnellement que si le calendrier international actuel survit à la dissémination de l’humanité sur des planètes aux calendriers tous différents, le changement d’orbite de la Terre après le début de l’agonie du Soleil posera le problème de manière plus aïgue. Cependant, dans les échelles de temps que nous considérons, on peut penser que l’homme saura préserver le Soleil dans son état actuel encore quelques quadrillions de millénaires, au moins sous une forme simplifiée utilisable pour les besoins du calendriers, ou sous forme de réalité virtuelle).
  • La probabilité que l’Homme se retrouve seul dans l’Univers est faible ; la coordination de nos dates avec les Gaz Sapiens de la Galaxie du Sombrero ou les Microbes Pensants de l’Amas d’Ophiuchus reste une question ouverte.
  • Le maintien sous une forme utilisable des archives datées après la Fin des Temps est incertaine.

Détails techniques

La notation ci-dessus oblige à revoir nombre de standards (MIME, SNMP, DNS...) qui se basaient naïvement sur des années à quatre chiffres. En revanche, posséder un nombre variable de chiffres dans une date évite les problèmes de buffer overflow exploitables par des pirates.

Délais

Le Bug de l’An Dix Mille se posera dans sept mille neuf cent quatre-vingt-treize ans, et même bien avant à cause des prévisions, crédits bancaires, etc. utilisant des dates futures.

À mon humble avis, vues l’évolution de l’immobilier, celle du recul de l’âge de la retraite, et les estimations optimistes de certains scientifiques sur les possibilités de prolongation de notre vie sur plusieurs siècles, ou sous forme numérique, les premiers crédits bancaires sur mille ans devraient voir le jour avant les années 2900. Le Bug Y10K se manifestera peut-être dans moins de six mille ans ! Il nous faut donc nous bouger ! Certains organismes proposent déjà leurs services.

Notes

[1] Mais que vaut l’immortalité en tant que simple processus tournant sur un système sous-dimensionné à partager avec quelques dizaines d’autres milliards d’entités numériques ?

[2] Et là je déplore que Dotclear, qui propulse le présent blog, ne permette apparemment pas de gérer les exposants...
Correctif : Il faut convertir le billet en XHTML auparavant et utiliser les balises HTML habituelles. Dommage que la syntaxe wiki ne le permette pas.

[3] NB : À ce stade, nous ignorons le problème posé par la poignée de milliards d’années d’avant Jésus-Christ.

[4] Remarquons qu’Oracle stocke les dates sous forme de nombre représentant les jours depuis une date reculée dans le passé ; les heures, minutes, secondes sont donc représentées par la partie fractionnaire du nombre, mais on ne descend pas au-dessous de la seconde en précision.