Discussion :

[Olivier Famien]

Après le passage au Nouvel An, plusieurs entreprises connaissent le bogue de l’année 2020 nommé Y2K20
à cause d’une solution paresseuse utilisée pour corriger le bogue du millénaire

À l’approche de l’année 2000, l’on se souvient encore du bogue de l’an 2000 provoqué par la mauvaise représentation des dates dans de nombreux logiciels et bases de données. Ce problème trouve son origine dans les années 60 lorsque la mémoire des ordinateurs coûtait encore très cher. Lors de la conception des logiciels, les développeurs codaient les dates avec 2 chiffres seulement pour économiser l’espace mémoire. Cette pratique qui s’est pérennisée jusque dans les années 1990 donnait par exemple 98 pour l’année 1998 et 99 pour l’année 1999. Sur cette base, en passant à l’année 2000, les 00 seraient interprétés dans les applications comme l’année 1900 au lieu de l’an 2000.

Pour résoudre le bogue du passage à l’année 2000 (abrégé également Y2K ou encore appelé bug du millénaire), certaines entreprises ont utilisé des solutions radicales comme la décompilation de leurs applications pour adopter une meilleure structure de données. D’autres entreprises ont mis à niveau leur application en faisant un appel de la date système qui n’est pas sujet à ce bug. D’autres entreprises par contre ont effectué de simples conversions en utilisant la technique de fenêtrage. Cette technique suppose par exemple que lorsque les deux derniers chiffres de la date utilisés sont supérieurs ou égaux 50, le système le traduit l’année par 19xx et s’il est inférieur à 50, le système le traduit par 20xx. Cette dernière solution est jugée comme celle des paresseux, car elle ne fait que repousser l’échéance du bug à 2050. D’autres par contre ont simplement décalé la fenêtre des dates 1900-2000 à 1900-2020.

Splunk, une multinationale américaine, qui produit plusieurs solutions pour rechercher, analyser et visualiser de grandes quantités de données a connu également un bogue semblable au bogue Y2K après le passage à l’année 2020. En effet, pour déterminer correctement les dates et heures en fonction des données entrantes, le processeur d’entrée de la plateforme Splunk utilise un fichier nommé « datetime.xml ». Le fichier utilise des expressions régulières pour extraire de nombreux types de dates et d’horodatages différents à partir des données entrantes.

Code XML :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
<!--   Version 4.0 --><!-- datetime.xml -->
 <!-- This file contains the general formulas for parsing date/time formats. --><datetime><datetime><define name="_year" extract="year">  <text><=!=[=C=D=A=T=A=[(20\d\d|19\d\d|[901]\d(?!\d))]=]=></text> </define>..</datetime>

Dans ce fichier, le code permet d’extraire des données pour lesquelles les années sont codées en deux chiffres jusqu’en 2019. Et donc jusqu’au dernier jour de l’année, pas de problème, le traitement des données est effectué sans problème. Mais « à compter du 1er janvier 2020, ces instances non corrigées traiteront par erreur les données entrantes comme ayant une année d’horodatage non valide, et pourraient soit ajouter des horodatages à l’aide de l’année en cours, soit interpréter la date de manière incorrecte et ajouter un horodatage avec la date mal interprétée ».

Splunk a fourni un correctif pour régler ce problème qui a eu cours sur sa plateforme cloud. En outre, pour les systèmes de type Unix, Splunk déclare également qu’à « compter du 13 septembre 2020 à 12 h 26 min 39 s, temps universel coordonné (UTC), les instances de la plateforme Splunk non corrigées ne pourront pas reconnaître les horodatages des événements avec des dates basées sur l’heure Unix, en raison d’une analyse incorrecte des données d’horodatage ».

Splunk n’est pas la seule entreprise à avoir connu le bug de l’année 2020 (appelé également bogue Y2K20). WWE 2K20 qui est un jeu de catch professionnel a commencé à boguer lorsque la cloche de minuit a sonné le premier jour de l’année 2020. Dès qu’un utilisateur sélectionnait un mode, le jeu se mettait à crasher. 2K Games, l’éditeur du jeu a fourni un patch et a demandé aux utilisateurs de redémarrer le jeu afin de l’appliquer.

Mais malgré cela, certains utilisateurs déclarent qu’ils rencontrent encore des bugs en jouant à ce jeu. Pour contourner le problème, certains ont trouvé la parade en ramenant la date du système au 31 décembre 2019.

Un utilisateur sur Twitter du nom de Jim Lippard a pour sa part rapporté que l’entreprise Cox, fournissant des services de télévision numérique par câble, lui a fourni une facture avec la date 1920.

Sur les systèmes de type Unix, il faut savoir que la mesure du temps est calculée en fonction des secondes écoulées à partir du 1^er janvier 1970 à 00:00:00 UTC. Selon les spéculations, certains développeurs auraient choisi comme fenêtre de dates pour résoudre le bug Y2K la période partant de 1920 à 2020 en raison du point médian qui est 1970. L’année 2020 étant arrivée, les logiciels implémentés de cette manière reviennent à la date la plus reculée qui est 1920.

En outre, les systèmes de type Unix utilisant la représentation des dates avec un entier signé de 32 bits pour calculer le temps écoulé pourraient également se retrouver dans la même situation de bug de l’an 2000 après le 19 janvier 2038 à 3 h 14 min 8 s. En effet, vu que la mesure du temps est calculée en fonction des secondes écoulées à partir du 1er janvier 1970 à 00:00:00 UTC (nommée également epoch), le nombre de secondes total est de 2³¹ – 1, ce qui fait que la date la plus reculée est le 13 décembre 1901 et la date la plus avancée est le 19 janvier 2038 à 3 h 14 min 8 s Lorsqu’il sera 3 h 14 min 8 s le 19 janvier 2038, le système passera au 13 décembre 1901 à la seconde suivante.

Source : Splunk, Twitter WWE 2K20, Twitter Jim Lippard

Et vous ?

Avez-vous déjà été confronté au bogue Y2K ou Y2K20 dans un logiciel ? Qu’en pensez-vous ?

Utilisez-vous encore le format de dates à deux chiffres pour récupérer les dates dans vos logiciels ? Pourquoi ?

Vu toutes les recommandations avancées pour éviter ce type de bugs, quels commentaires faites-vous des développeurs qui continuent de coder leurs logiciels avec le format de dates à deux chiffres ?

Voir aussi

Le « bug de l’an 2000 » se reproduira en 2038 dans le monde Linux, mais c’est maintenant qu’il faut s’inquiéter selon Jon Corbet
Apple sort iOS 11.2.6 pour corriger un bogue lié à un caractère indien qui fait planter l’OS et les applications de messagerie
Un bogue dans un code Python pourrait avoir causé des erreurs de calcul dans plus d’une centaine d’études scientifiques publiées depuis 2014
Apple, Microsoft et Orange victimes d’un bogue de l’an 2011, avez-vous constaté d’autres dysfonctionnements du même type ?

[mcoppa]

Chez nous, on avait choisi de noter 2000 en A0, 2001 A1, 2010 B0 2011 B1 etc. Donc 2020 est devenu C0. On est encore tranquilles jusqu'en 2260...

[m50mlef]

J'ai connu les cartes perforées. Les dates codées sur 8 caractères, ça faisait trop cher, sur une carte qui n'en offrait que 80...

[Invité]

Sur Mainframe, le format décimal condensé, le fameux COMP-3 en COBOL, existe depuis les années 1960. On peut stocker une date de 8 chiffres sur 5 octets :0yyyymmdS
(S = signe, on perd juste un demi-octet à gauche; qui reste à zéro). Mieux que 6 chiffres en étendu (format DISPLAY). Il y a des économies de bouts de chandelles qui coûtent très chers sont sont très problématiques sur le long terme.

[tpericard]

Avez-vous déjà été confronté au bogue Y2K ou Y2K20 dans un logiciel ? Qu’en pensez-vous ?
Au bogue Y2K oui.

Une solution paresseuse était effectivement le fenêtrage. Solution qui, au passage, nécessitait quand même de retester l'ensemble des applicatifs concernés. Pas forcément très simple, ni très rapide. Pour "défendre" un peu cette solution, faut avoir à l'esprit 2 choses :

1 - c'était une solution purement logicielle, qui n'avait pas d'autres impacts (technique, bases de données, etc … ). Solution au moindre coût certes, mais contrainte parfois par des raisons purement financières !

2 - tout dépend sur combien de temps on gère ce qui vit dans le SI concerné. Exemple, si c'est sur moins de 10 ans, un fenêtrage sur les 2 chiffres '90' suffisait amplement. D'ici 2090, il y a de fortes chances que l'application concernée soit remplacée …


Utilisez-vous encore le format de dates à deux chiffres pour récupérer les dates dans vos logiciels ? Pourquoi ?
Maintenant je programme beaucoup moins (faisant plutôt du test). A part des utilitaires en VBA pour faciliter mon travail de testeur, je ne fais, pour l'instant, rien d'autre. Quand j'ai à manipuler des dates, j'utilise le format de date à 4 chiffres pour les années !


Vu toutes les recommandations avancées pour éviter ce type de bugs, quels commentaires faites-vous des développeurs qui continuent de coder leurs logiciels avec le format de dates à deux chiffres ?
Je ne pense pas que les développeurs continuent à coder avec seulement 2 chiffres pour les années