Dans cet article, nous allons parler de l’éternel “piège” auquel sont confrontés les programmeurs Java lorsqu’il est question d’une tâche aussi simple que celle qui consiste à afficher l’année.
Si vous dites à Java de traiter la date sous la forme de quatre chiffres en utilisant l’abréviation AAAA, qui est une façon très courante de désigner l’année dans toutes sortes d’autres applications, vous obtiendrez la bonne réponse la plupart du temps …
… mais certaines années, la résultat s’affichera avec une année de décalage pendant seulement quelques jours au début ou à la fin de l’année civile.
Des réminiscences du bug de l’an 2000 (le fameux bug Y2K) !
Le bug Y2K concernait les programmes qui tentaient d’économiser de l’espace mémoire en stockant les dates sous cette forme “99” plutôt que sous celle-ci “1999” et qui se sont retrouvés face à un problème fin 1999, car la somme 99+1 donne 00 lorsque vous n’avez que deux chiffres avec lesquels jouer.
Mais il s’avère que le bug Java auquel certaines personnes comparaient le bug Y2K était en réalité un problème complètement différent.
Le bug dans le cas de Java est que le raccourci Java pour désigner l’année en cours sur quatre chiffres est aaaa, et non AAAA, l’utilisation ou non des majuscules est ici primordiale.
De manière plutôt confuse, allant même jusqu’à surprendre de nombreuses personnes, le texte AAAA dans un programme Java indique l’année au cours de laquelle se trouve au moins la moitié de la semaine en cours, comme dans le cas des activités liées à la paie et à la comptabilité hebdomadaire.
Donc, s’il y a quelques jours au début ou à la fin d’une année, ils sont transférés à l’année précédente ou suivante lorsque vous comptez en semaines au niveau de votre comptabilité.
Waouh !!
En fait, quand vous y pensez, l’idée d’un bug similaire à celui de l’an 2000 refaisant surface à la fin 2019 semble assez improbable.
Des programmes qui n’utilisaient que deux chiffres pour afficher l’année au lieu de quatre ont sûrement été découverts le jour du Nouvel An 2000, et ont été augmentés de 100 années depuis, et ont donc rapidement été corrigés ou remplacés, n’est-ce pas ?
Ou bien peut-être pas !
En effet une façon de traiter le problème révélé par le bug de l’an 2000 a été de le déplacer, plutôt que de le corriger à proprement parler.
En d’autres termes, au lieu de retravailler votre programme afin qu’il puisse calculer correctement que 1999+1 = 2000 (et ainsi de suite pour toute année à quatre chiffres), vous pouvez prendre un raccourci et simplement dire à votre programme de traiter le 00 comme correspondant à l’année 2000 Après J.-C., et non 1900 Après J.-C., vous donnant ainsi une année supplémentaire pour régler correctement le problème.
Il existait néanmoins un inconvénient, à savoir que vous n’aviez plus aucun moyen de désigner l’année 1900, mais c’était souvent beaucoup moins un problème que de ne pas pouvoir reconnaître correctement l’année 2000 : au final vous avez accepté le risque de voir apparaître des bugs très occasionnels qui pourraient d’ailleurs ne jamais se présenter, en sécurisant la situation et en évitant d’avoir à faire face à un véritable chaos à minuit le jour du Nouvel An 2000.
Bien sûr, cette astuce pourrait être utilisée pour vous donner plus d’une année supplémentaire. Par exemple, à la fin 2000 si vous n’aviez toujours pas réussi à corriger votre logiciel avec des années sur quatre chiffres, vous pourriez de nouveau décaler le point de transition vers la fin 2001 à la place, vous perdriez alors 1900 et 1901 mais vous gagneriez 2000 et 2001.
Vous pouvez deviner où cela nous mène, à savoir qu’une telle astuce qui fonctionne pour un ou deux ans peut fonctionner pour 10 ans …
… ou pour 20 ans.
Le bug Y2K version 2.0 ?
Nous avons découvert récemment de nombreux récits dans les médias relatant que divers systèmes informatiques dans le monde semblaient avoir utilisé une telle méthode, à savoir un report du problème lié à l’an 2000 jusqu’en 2020 en décalant le point de transition jusqu’au 31/12/2019.
Un cas notable est celui des parcmètres à New York, où, selon le Département des Transports de la ville :
[L]e logiciel du système de paiement par carte de crédit a été configuré pour se terminer le 1er janvier 2020, et les responsables disent que […] l’entreprise qui a fabriqué les compteurs n’a jamais changé de date. Les paiements par carte ont cessé de fonctionner le jeudi 2 janvier 2020.
Voici donc un bug Y2K version 2.0 !
En fait, nous ne savons pas s’il s’agissait d’un bug de type Y2K ou simplement d’un problème opérationnel avec une cause différente.
Après tout, si les appareils ont été victimes d’une erreur de calcul de 100 années lors de la transition de 2019 à 2020, vous pouvez raisonnablement vous attendre à ce que le système soit défaillant le jour de l’An, plutôt que le deuxième jour du mois.
Mais la morale de cette histoire est simple, et elle va bien au-delà du simple fait d’afficher correctement l’année.
S’il existe dans votre logiciel un paramètre qui “arrête-brusquement-de-faire-fonctionner-un-composant-pour-une-raison-quelconque“, et il existe de nombreuses bonnes raisons pour en créer un, que ce soit pour forcer la mise au placard définitive du code remplacé depuis longtemps ou pour se conformer à de nouvelles réglementations ou encore à d’autres fins, alors ne vous laissez pas surprendre.
Enfin, une dernière chose
Soit dit en passant, le support de Windows 7, y compris la publication de mises à jour et de correctifs de sécurité, s’est arrêté complètement 14 janvier 2020.
Ne vous laissez pas surprendre non plus !
Bien que Windows 7 ne s’arrête pas brusquement de fonctionner, il existe probablement de nombreux responsables IT et employés qui le souhaitent secrètement.
Cela sortirait au moins de l’ombre tous ces ordinateurs Windows 7 inconnus et non signalés …
Billet inspiré de Is the Y2K bug alive after all?, sur Sophos nakedsecurity.
Qu’en pensez-vous ? Laissez un commentaire.