Le bug de l’an 2038

Le bug de l'an 2038

La dernière fois, nous avons parlé du fameux bug de l'an 2000 (alias Y2K ou « Why touquet ? » pour la blague, hoho qu'est-ce qu'on se gausse oulalah je n'en peux plus j'ai mal aux côtes). Passons au vif du sujet : le bug de l'an 2038.

(Enfin, si mon smiley me lâche un peu la grappe, je pourrais peut-être passer au vif du sujet.)

DONC.

💡 Lors du passage à l'an 2000, les systèmes de type Unix n'ont pas eu trop de souci, et pour cause : les dates n'y sont pas stockées sur deux chiffres décimaux mais sur 32 bits (soit 4 octets*).

✷ Si vous êtes largués, je vous renvoie à l'article « Bit, Byte, Bitten ».

▶️ Pour être précis, la date et l'heure sont communément stockées dans un nombre unique que l'on appelle « timestamp » et qui correspond au nombre de secondes écoulées depuis l'origine du temps.

⚠️ Petite précision : quand je dis « l'origine des temps », je ne parle bien sûr pas de l'an 0 de notre calendrier grégorien mais du 1^er janvier 1970 à minuit précise.

Pourquoi cette date ?

Bon, en fait c'est juste que ça s'est décidé au début des années 70 et qu'on a pris au plus proche.

(D'ailleurs ce fut un temps le 1^er 1971 qui avait été choisi, allez savoir pourquoi.)

Bref.

La date est donc stockée dans un nombre entier, un « integer » de son petit nom en anglais.

✷ #trueStory, si on pouvait prévenir les profs d'info de France qui enseignent la faute de prononciation à chaque génération d'élèves…

▶️ Il s'agit souvent d'un entier signé, c'est-à-dire que sur les 32 bits, il y en a un qu'on utilise pour savoir si le nombre est négatif ou positif.

✷ Led Zeppelin. Ouais, ils ne sont pas nés le 1er janvier 1970 mais Jésus de Nazareth n'est pas non plus né le 25 décembre 0 alors de quoi j'me mêle, hein.

⚠️ Ce dont il faut bien avoir conscience, c'est que si ce timestamp est stocké sur une taille fixe (31 bits + le bit de signe), c'est bien qu'il a une valeur maximum.

Nous pouvons donc, à l'aide de ces valeurs, donner la date de la fin du monde dans l'univers Unix, exactement 2 147 483 647 secondes après le 1^er janvier 1970 à minuit :

💡 Ensuite, que va-t-il se passer ? Eh bien, plus ou moins la même chose qu'avec le bug de l'an 2000 : on va reboucler sur la plus ancienne date représentable.

Alors, comment faire pour régler ce problème qui va arriver relativement vite ?

Surtout si on travaille déjà avec des dates d'un futur assez lointain…

✷ Dépassement d'entier : ce qui arrive quand on essaie de compter au-delà du maximum représentable par un integer (exactement le bug de l'an 2038 donc).

✷✷ Et là, il va se passer quoi ? Un ? Un ? Un bug. Suivez, un peu.

▶️ Plusieurs solutions : tout d'abord, bien sûr, passer à un format non-signé (le bit de signe est donc remplacé par un bit standard, ce qui porte la taille du nombre à 32 bits).

▶️ Ou bien sûr, stocker les dates sur 64 bits au lieu de 32, ce qui est d'ailleurs déjà le cas sur les systèmes Unix 64 bits. Du coup la date butoir se situerait dans 292 milliards d'années. C'est-à-dire dans vachement longtemps.

Non mais sérieusement, quand je dis vachement longtemps, c'est…

Vachement.

Longtemps.

Pour conclure, on entendra sans doute quand même parler du bug de l'an 2038 dans les années à venir.

Parce que même si la plupart des systèmes seront à jour d'ici là, il ne faut jamais sous-estimer l'inertie en informatique…