Ceci est une version allégée d’une des pages de mon site : Le Bug de l’An 2000… et les autres, qui contient notamment beaucoup plus de liens.

Avant l’An 2000

  • 1er janvier 1970, 1er janvier 1980 : Certains programmes, parfois sur cartes perforées, ne codaient l’année que sur un chiffre… Le phénomène a eu lieu surtout en 1970, mais tout le monde n’avait pas retenu la leçon la décennie d’après.

    (Rappel de théorie : De manière générale, un tel problème de date dépend de :
    • (1) la date de départ ;
    • (2) l’espace octroyé pour la différence par rapport à cette date ;
    • et (3) la résolution employée.

      Le Bug de l’An 2000 sous-entend une date de base en 1900, 2 chiffres en base 10 pour la stocker, et une résolution d’un chiffre par an : il « boucle » en 2000.
      Le système ci-dessus part de 1970, sur un chiffre en base 10, consommé un par an.
      Le système Unix actuel part de 1970, utilise 32 bits (2^31 valeurs) qui s’incrémentent de 1 par seconde, et bouclera en 2038.)
  • 1975 : Premières manifestations du Bug de l’An 2000 dans les programmes qui calculaient les échéances de crédits bancaires sur 25 ans.
  • 1er janvier 1976 : Les petits malins qui en 1970 avaient décidé de passer l’unique chiffre des années de décimal en hexadécimal (donc avec A=11, B=12… jusque F=15), ont vu le bug les rattraper à nouveau.
  • Vers 1977 : On rapporte qu’une vieille dame du Midwest aurait, à 105 ans, été conviée à s’inscrire à l’école.
  • 1er janvier 1978 : Crash des machines qui tournaient sous OS/8 sur PDP-8 et 12. La date était stockée sur 3 bits à compter de 1970.
  • 17 août 1979 (?) : Un programme avait cette date comme indicateur de fin de fichier. Le fournisseur conseillait vivement de ne PAS utiliser le logiciel cette date ou de mentir sur la date.
    (On notera que les fournisseurs de l’époque semblaient plus honnêtes que ceux de maintenant et n’attendaient pas que d’autres trouvent les bugs pour avertir leurs utilisateurs.)
  • 1er janvier 1980 : Un programme scientifique nommé MACRO-11, sur un des derniers PDP-11, se croit en 197:.
  • 4 janvier 1980 : Jour Zéro où reviennent la plupart des PCs qui ont oublié leur date.
  • 13 octobre 1983 : Digital répond à un appel support d’un de ses client qui se plaint que 2000 est interprété comme une année bissextile - comme quoi le problème était parfois dans l’humain, pas dans la machine….
  • 4 janvier 1987 : 2^29 secondes après le fatidique 1er janvier 1970 (premier avertissement pour le Bug de 2038). Des programmes en Common Lisp ont eu des problèmes de recompilation.
  • 1989 : Le Japon, à la mort de l’empereur Hiro Hito, a changé d’Ère, et les dates y sont à nouveau comptées à partir de 1.
  • 31 décembre 1995 : Première date qui pour certains programmes signifiait « Pas de date de fin de validité », c’est-à-dire l’infini. Arrivés à cette date certains programmes vont commencer à effacer des données qu’ils croient périmées.
  • Mai 1997 : Une base de donnée nommée Advanded Revelation comptait les jours à partir du 1er janvier 1970. Le passage de 4 à 5 chiffres a causé quelques bugs.
  • 1er janvier 1999 : Nouvelle manifestation du 99 comme date limite. Au même moment, des centaines de millions d’Européens passent à l’euro et doivent abandonner leurs monnaies nationales.
    Globalement, le système bancaire s’est adapté sans problème ; quelques problèmes à la Poste au tout début, et dans les taxis de Singapour en guise de bug avancé.
  • 1er avril 1999 : En guise de poisson, le magazine allemand C’t annonce que des documents sur la mise en place du calendrier grégorien en 1582 ont été découverts, précisant que les années divisibles par 400 ne sont bissextiles que si non divisibles par 1000 ; 2000 n’est donc pas bissextile.
  • 22 août 1999, 0h : Des systèmes GPS ont pu se croire à nouveau le 6 janvier 1980.
    Ce passage s’est apparemment bien déroulé car les systèmes récents tenaient compte du problème, sauf pour quelques voitures japonaises à balise GPS.
  • 9 septembre 1999 : Le code 9/9/99 était souvent utilisé dans les années 80 comme date d’expiration non valide (archives permanentes). Des données risquaient donc d’être automatiquement effacées ce jour-là…
    Vérification faite, ce problème relevait plus du canular que de la réalité. À moins que la sensibilisation sur le bug de l’an 2000 n’ait permis aussi l’éradication de ce bug au passage.
  • 31 décembre 1999 : Encore une date qui comme le 9/9/99, signifiait « Ne pas effacer », surtout dans le monde des mainframes IBM.

À suivre…