Ouf, le bug de l’an 2038 devrait ressembler à celui de l’an 2000

Nicolas Furno |

Les plus jeunes qui lisent ces lignes n’auront peut-être pas connu le bug de l’an 2000. Et même si vous l’avez connu, vous l’avez sans doute entièrement oublié, et pour cause : l’apocalypse informatique annoncée n’a pas eu lieu. C’était une peur importante tout au long des années 1990, on imaginait alors que tous les ordinateurs allaient planter le 1er janvier 2000 à minuit. L’année 1999 s’est finalement terminée sans incident majeur1.

La Tour Eiffel a affiché un immense compteur pour le passage à l’an 2000, un compteur qui n’a d’ailleurs pas planté le 1er janvier 2000 à minuit (photo nhayashida (CC BY 2.0))

Ce devrait être en gros ce qui se passera aussi en 2038. Car oui, c’est le 19 janvier 2038 à trois heures, quatorze minutes et sept secondes UTC, soit 5h14 du matin en France, que le prochain bug du même genre pourrait avoir lieu. À cette date précise, les ordinateurs, qui mesurent le temps en nombre de secondes qui se sont écoulées depuis 1970 par convention, auront atteint la limite de ce qu’un nombre encodé sur 32 bits peut stocker.

Pour résumer la situation rapidement, les dates sont enregistrées en informatique avec un « timestamp » (horodatage en français), une série de chiffres qui représentent le temps. Le plus commun est le timestamp UNIX qui est constitué du nombre de secondes qui se sont écoulées depuis le premier janvier 1970 à minuit. Par exemple, le timestamp UNIX correspondant à la publication de cet article est 1603271700, soit environ 1,6 milliards de secondes après cette date choisie, ce qui correspond au 21 octobre 2020 à 09h15 en France.

Ce choix est pratique : en utilisant une valeur unique, tous les ordinateurs peuvent échanger entre eux, quel que soit leur fuseau horaire et surtout quelle que soit la manière d’encoder la date. Vous savez peut-être que les Américains commencent par le mois, si bien que la date du jour est 10/21/2020 aux États-Unis, alors que nous commençons par le jour, 21/10/2020. Mais dans les deux cas, le timestamp UNIX est identique, ce qui est indispensable notamment pour communiquer via internet.

Un timestamp UNIX affiché dans le terminal de macOS.

Cette technique est née dans les années 1970 en même temps que les systèmes UNIX et c’est pourquoi cette date symbolique a été choisie. Cette méthode de notation n’a aucune limite en soi, mais il y en a une qui surviendra en 2038 : si le timestamp est encodé en 32 bits, alors on aura atteint le nombre maximal de chiffres qui peut être exprimé. Quand le timestamp atteindra 2147483647, il ne pourra plus être incrémenté. À partir de là, soit la date du système reviendra à 0, soit le système plantera et on obtient le bug de 2038.

C’est inquiétant, mais le bug de l’an 2000 a servi de leçon et on est prêt à gérer ce cas de figure. Pour commencer, tous les systèmes d’exploitations 64 bits utilisent un timestamp UNIX encodé lui aussi sur 64 bits. On estime que le nombre de secondes qu’il peut contenir est environ vingt fois plus important que la durée de l’univers, autant dire qu’on sera tranquille pour un moment. Apple utilise cet encodage depuis Snow Leopard (macOS 10.6), même si c’est El Capitan qui corrige entièrement le problème.

Les bugs pourraient persister pour les anciens systèmes restés en 32 bits, comme les anciens Mac bloqués à une version antérieure du système. On peut déjà savoir ce qui va se passer : sur un Mac équipé de Tiger (10.4), le système ne peut pas dépasser le 31 décembre 2037 par sécurité, il revient à cette date si on essaie de le configurer au-delà. Sur d’autres modèles, on sait que le bug se manifestera par un retour à une date antérieure2.

L’un des rares signes visibles du bug de l’an 2000 : un panneau d’affichage de l’école Centrale de Nantes retourné en l’an 1900, sans doute parce que la date était encodée sur deux caractères seulement3 (Wikimedia Commons (CC BY-SA 3.0))

Pour les ordinateurs 32 bits sous Linux, les créateurs du noyau ont prévu un correctif qui permettra de gérer les dates jusqu’en 2486. Le plus gros problème potentiel devrait toutefois venir des multiples ordinateurs embarqués, par exemple dans les voitures, qui pourraient encore fonctionner. On ne parle pas des ordinateurs de bord, mais bien des systèmes informatiques qui gèrent des fonctions essentielles comme l’ABS, l’ESP et autre.

Ces ordinateurs sont en général limités par des processeurs 32 bits, mais leur utilisation de la date est restreinte. Il s’agit souvent de déterminer des durées, ce qui veut dire qu’ils devraient pouvoir passer de 2038 à une date antérieure sans créer de problèmes majeurs. Dans quelques cas précis, il faudra peut-être mettre à jour des composants anciens de machines ou véhicules avant l’année 2038.

Quoi qu’il en soit, vous pourrez vous endormir tranquilles ce soir, ce nouveau bug devrait bien être aussi mineur que le précédent…


  1. Ce qui ne veut pas dire qu’il n’a pas fallu travailler en amont. Comme vous le rappelez fort justement dans les commentaires, de nombreux programmes ont été mis à jour pour éviter les bugs qui auraient eu lieu avec le passage à l’an 2000.  ↩︎

  2. Un nombre encodé en 32 bits peut évoluer entre 2147483647 et -2147483647. Si l’ordinateur atteint la valeur supérieure, il ne revient pas à 0, mais à la valeur minimale, soit -2147483647. Et comme le timestamp UNIX fixe le 0 au premier janvier 1970, cet horodatage correspond au 13 décembre 1901 à 20h45 et 52 secondes.  ↩︎

  3. Pour optimiser le stockage, denrée extrêmement rare et précieuse les premières années de l’informatique, on encodait parfois les dates sur deux caractères : « 75 » pour 1975, « 91 » pour 1991, etc. Une bonne idée sur le papier, mais les développeurs n’avaient pas anticipé qu’à partir de 2000, le programme considérerait qu’on était revenu en 1900 plutôt qu’en approche du XXIe siècle. C’est très certainement ce qui s’est passé pour ce tableau d’affichage.  ↩︎


Tags
#Bug #Unix
avatar Link1993 | 

Dites, votre conversion de l'UTC... vous êtes sur qu'en 2038 y'aura encore l'heure d'hiver ? 😏

avatar Nicolas Furno | 

@Link1993

Ah ça, je dois dire que je n'y avais pas pensé ! 🙂

avatar Link1993 | 

@nicolasf

Je vis en UTC tous les jours... Je vois ça tout de suite ! 🤣

avatar SartMatt | 

Ah noter que la conversion en heure d'été n'est pas plus juste... Car si le fait de supprimer le changement d'heure est bien acté, le choix entre UTC+1 et UTC+2 n'est pas encore fait il me semble.

avatar Nicolas Furno | 

@SartMatt

Je vais laisser comme ça, de toute façon le Covid-25 ou 32 aura peut être réglé la situation d’ici là.

avatar melen | 

@Nicolas Furno
Quelle forme !

avatar JonasL | 

On estime que le nombre de secondes qu’il peut contenir est environ vingt fois plus important que la durée de l’univers, autant dire qu’on sera tranquille pour un moment.

HAHAHAHA

avatar clemcoste | 

Super article merci !

avatar saoullabit | 

@Nicolas Furno avoir un Shell ZSH pimpé c’est comme porter des chaussettes en sandalettes : c’est la Classe

Pimp my shell
https://github.com/sorin-ionescu/prezto

Glitter all over my pimped shell
https://github.com/romkatv/powerlevel10k

(Oui, oh my zsh! toussa... prezto me convient mieux)

avatar Nicolas Furno | 

@saoullabit

Team oh-my-zsh ici ! 🙂

Mais je change pas grand-chose, en effet.

avatar saoullabit | 

@nicolasf

Brave heart !
En mode bonhomme team Prezto !

avatar Skittou | 

Les contrôleurs embarqués dans les voitures et gérant les fonctions essentielles telles que décrites n'utilisent que très peu les dates, voire pas du tout. J'ai fait du dev logiciel sur des contrôleurs de boîte de vitesses automatique, on n'utilisait jamais les dates. Et même pour des fonctionnalités liées à l'entretien (allumer le témoin de remplacement d'huile par exemple), on se contentait d'incrémenter un compteur en fonction des conditions d'utilisation. Donc pas de soucis.

avatar jackhal | 

"Les contrôleurs embarqués dans les voitures et gérant les fonctions essentielles telles que décrites n'utilisent que très peu les dates, voire pas du tout."

Je dois dire que quand j'ai lu " On ne parle pas des ordinateurs de bord, mais bien des systèmes informatiques qui gèrent des fonctions essentielles comme l’ABS", j'ai ri.
Après, on n'est pas à l'abri d'un code complètement farfelu, mais bon, quand même. :-D

avatar flepr | 

« La Tour Eiffel a affiché un immense compteur pour le passage à l’an 2000, un compteur qui n’a d’ailleurs pas planté le 31 décembre 1999 à minuit »

En fait, pour avoir été devant la Tour Eiffel pour le passage à l’an 2000, je me souviens bien que le compteur avait buggé quelques minutes avant minuit et qu’on n’avait du coup même pas eu le décompte sur le compteur géant !! 😭🤦‍♂️
Mais en effet, rien à voir avec le bug de l’an 2000 a priori ! 😉

avatar Bhaal | 
avatar Xalio | 

@flepr

Je m’en souviens aussi! (Retransmit à la TV)

avatar koko256 | 

Il faut peut-être préciser dans l'article que c'est 32 bits signés sinon on a un peu plus de temps (2106). Du coup après 2038 on ne tombe pas à 0 mais un nombre négatif. Au mieux une date avant 1970 (a priori 1902).
Il faut peut-être aussi préciser que même si l'OS est en 64 bits, si le programme est en 32 bits, il aura le même problème car il ne recopiera que les 32 bits de poids faible de l'heure renvoyée par le système.

avatar Nicolas Furno | 

@koko256

C’est vrai que ça m’a surpris ce retour au début du siècle. Ça vient d’où le chiffre négatif ?

avatar bl@ck warrior_69 | 

@nicolasf

Le 32 bits va de -2,147,483,648 à + 2,147,483,648 il me semble non ? Donc si on considère qu'en 2038 on aura atteint la valeur Max et que le 0 c'est 1970, alors si le compteur repart sur la valeur minimale (en passant de +2,147,483,648 à -2,147,483,648, plutôt que de revenir à 0), on tombe sur 1902.

avatar Nicolas Furno | 

@bl@ck warrior_69

Aaah bien vu. Je vais ajouter l’explication, merci !

avatar dodomu | 

@nicolasf

Sur x bit on peut représenter 2 puissance x valeurs différentes.
Chaque combinaison unique de bit correspond usuellement à un nombre, mais ça pourrait très bien être la liste de tout les coloris d’iPhone que ça serait pareil...
Mais revenons à la représentation de nombre : il existe plusieurs façons d’attribuer un nombre entier à une combinaison de x bit, les deux les plus courante sont : le non signé et le signé.
Le premier permet de représenter un entier sans son signe, on a alors des nombres allant de 0 à (2^x)-1.
Mais avec ce système on ne peut stocker que des nombre sans signe (impossible de savoir s’il sont positif ou négatif, par convention on les considère négatif).
On a donc inventé la possibilité de réserver un des x bits pour stocker le signe, ce qui permet usuellement de stocker des nombres entier allant de -2^(x-1) a 2^(x-1)-1.

avatar vince29 | 

> C’est vrai que ça m’a surpris ce retour au début du siècle. Ça vient d’où le chiffre négatif ?

Faut demander à wikipedia https://fr.wikipedia.org/wiki/Bug_de_l%27an_2038.

Le point de départ c'est le 1er janvier 1970 et si tu peux coder les dates jusqu'à 2038 (avec les valeurs positives) cela fait environ 68 ans.
Symétriquement tu peux aussi coder -68 ans avec les valeurs négatives soit jusque 1902 (en fait 13 décembre 1901)

avatar hairsplitter | 

Au moins ça nous rajeunira, c'est une bonne chose.

avatar Kubusiu | 

"Le plus gros problème potentiel devrait toutefois venir des multiples ordinateurs embarqués, par exemple dans les voitures, qui pourraient encore fonctionner"
en même temps, j'ose imaginer qu'en 2038 nos vieilles voitures thermiques auront été reléguées au rang de voitures de collection... Pas trop d'inquietude donc... 😌

avatar Valiran | 

@Kubusiu

Ou alors les écolos auront fermé toutes les centrales nucléaires et nous ferons face à une crise de l’électricité :)

Pages

CONNEXION UTILISATEUR