À 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.
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 1er 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 231 – 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.