Les autres Bugs qui nous attendent :

  • 2004/2005/2006 : Les écoles commencent à voir arriver des élèves nés en 2000.
  • 09/09/2009 : Mois, jour, année sont identiques, il est possible qu’on ait des bugs similaires à ceux du 9 septembre 1999.
  • 2010 : C’est l’année prévue pour le passage de IPv4 à IPv6 (voir mes billets sur le sujet), c’est-à-dire de l’ancienne à la nouvelle version du protocole de communication d’Internet.
    Il n’est pas sûr que cela se fasse, même si la nouvelle version de IP permettra de lever la pénurie d’adresses IP (mal réparties dès le départ) et d’ajouter des fonctionnalités. Le parc installé étant important, la transition promet d’être rude. Certains supposent que NAT et masquerading devraient suffire à jamais, ce qui rendrait la gestion du Réseau bien plus délicate...
  • 1er janvier 2010 : Dépassement de capacité pour certaines implémentations de la librairie C ANSI.
  • 1er janvier 2020 : Les macros Excel pèteront les plombs : 1/1/19, au moins sous les moins récentes versions d’Excel, signifie 1/1/2019, mais 1/1/20 c’est 1920... De même, les panneaux de contrôle des Macs ne permettront plus le réglage.
  • 2025 (environ) : Certains prévoient une saturation des codes américains à 7 chiffres pour le téléphone et les codes postaux.
  • 1er janvier 2028 : Certains programmes avec la date sur 7 bits reviendront à 0 (en fait à 1900, vu qu’ils étaient déjà revenus à 100 en 2000, et que certains se sont sans doute contentés d’ajouter 1900).
  • 1er janvier 2030 : Pour le même genre de raison, certains PC sous Windows pèteront les plombs. Cette date pourra différer (2040, 2050...) selon les machines. En effet, les dernières versions de Windows permettent à l’utilisateur de choisir quelle date fera office de "pivot" entre les deux siècles (en général 2030, les dates à 2 chiffres supérieures à 30 étant interprétées comme 19xx).
  • 1er janvier 2032 : Dépassement de capacité pour de vieux Macs et machines sous PalmOS.
  • 6 février 2036 : Répétition du bug de 2038 avec les systèmes qui comptent les dates sur des entiers de 32 bits non signés depuis le 1er janvier 1900. (Simple décalage de 70 ans du bug de 2106).
  • 1er janvier 2037 : Retour à zéro pour les serveurs NTP.
  • 19 janvier 2038, 3 h14 min 08 s : Les compteurs des programmes en C respectant la norme POSIX atteindront 2^31 secondes (après le 1er janvier 1970) et reviendront à zéro (ou plutôt au vendredi 13 décembre 1901, 20 h 45 min 52 sec).
    D’ici là on suppose que tous les programmes (notamment toutes les versions d’Unix) auront été recompilés avec une date en 64 bits, ce qui devrait suffire pour 300 milliards d’années. Mais la conversion provoquera des bugs collatéraux, et il est probable que quelques-uns des millions de systèmes 32 bits actuels seront encore là en 2038.
    (Mise à jour de janvier 2008, trente ans pile avant le bug) Selon les commentateurs de cette enfilade, soit ce sera du gâteau parce que tout sera recompilé en 64 bits d’ici là, soit ce sera une catastrophe parce que ce bug sera beaucoup plus délicat (et moins médiatisé) que celui de l’an 2000.
  • 6 février 2040 : Retour à zéro pour d’anciens Macintoshs et les regrettés Newtons. Encore le bug de 2036, mais calculé depuis 1904 cette fois. Apple a même une page sur le sujet (démarrer de 1904 simplifie le calcul des années bissextiles).
  • 17 septembre 2042 : Retour à 0 pour de vieux mainframes IBM. Ce serait un équivalent du bug de 2036 avec des updates intervals à la place de secondes. Mise à jour déjà prévue pour étendre le format.
  • 1er janvier 2044 : Dépassement de capacité 26 années après 1980 pour les derniers systèmes sous DOS.
  • 1er janvier 2046 : Dépassement de capacité pour ce qui restera des Amiga.
  • 2050 à 2075 : Dépassement du milliard pour les numéros de Sécurité Sociale américains.
  • 2048 : Le vrai bug Y2K, pour ceux qui auront utilisé le même K que dans kilo-octet, qui vaut 1024 ;-) (en fait Y2Ki pour les puristes).
  • 1er janvier 2100 : Beaucoup de BIOS de PC n’iront pas plus loin, si jamais ils ont duré jusque là.
  • 1er mars 2100 : Première année divisible par 4 de l’ère informatique dont le 29 février ne sera PAS bissextile !
  • 7 février 2106 06:28:15 : Répétition du bug de 2038 pour les machines utilisant encore des 32 bits non signés. (C’est loin ? Pensez que certains des enfants nés il y a peu verront cette date).
  • 11 avril 2262 : Si le bug de 2038 est résolu avec un système à 64 bits signés, et qu’on en profite pour utiliser une résolution d’une nanoseconde, les nouveaux systèmes retourneront au 21 septembre 1677.
  • 28 novembre 4338 : Dépassement pour les programmes respectant la norme ANSI Cobol 85 : on est arrivé à 10^6 jours après l’origine des temps du 1er janvier 1601.
  • 31 décembre 9999 : Date maximale qu’Oracle accepte, et considérée comme l’infini pour certains programmes.
  • 1er janvier 10 000 : Le bug de l’an 10 000 ! Il est possible que nous nous y frottions : ce siècle pourrait voir démarrer des projets (voyages interstellaires, terraformation de Mars, enfouissement de déchets nucléaires...) qui dureront des milliers d’années. Ou nous inventerons tout bêtement les traitements d’immortalité.
    Les éventuels programmeurs Cobol en sommeil cryogéniques seront ranimés d’urgence.
  • 19 100 : Des programmes soumis à certains bugs de l’an 2000 attendront cette date pour recommencer à fonctionner.
  • 29 940 : Le système de dates des Macintosh (OS 9) s’effondrera à son tour si 2020 n’a pas déjà été fatal.
  • 31 juillet 31 086 : Dépassement de capacité pour les DEC VMS.
  • 586 418 (à peu près) : Les vieux systèmes VAX (qui comptent sur 64 bits le nombre de microsecondes depuis 1860) feront tilt.
  • 5 000 000 ap. J.-C. : Les programmes en Java ne sont pas conçus pour aller au-delà de cette date.
  • 4 décembre 292 277 026 596 ap. J.-C. : Les programmes en C avec date sur 64 bits qui ont échappé au bug de 2038 se croiront à nouveau en 1970.