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 BordelInside | 

@beteldor

ça dépend : en EPS, si tu cours vers les vestiaires pour te mettre à l'abris plutôt que d'aller faire des tours de stade sous la pluie comme un con, le prof va vite te corriger la trajectoire.

avatar vince29 | 

Si LE PS ne corrige pas sa trajectoire il est pas sorti de l'ornière

avatar Fluo | 

Le vrai problème c’est le bug de l’an 10000, et personne ne semble s’en préoccuper.

avatar jbmg | 

@Fluo, c'est ben vrai 😂
Drôle d'époque, le logiciel professionnel avait reçu une correction pour avoir l'année sur 4 chiffres.
A l'époque, le logiciel de base de données que j'utilisais (ADN de Claude Colin) prenais la date sur 2 caractères, heureusement que j'étais resté en relation avec son concepteur qui m'a fait parvenir une correction alors qu'il avait arrêté son développement.
Au début du Mac (1984), c'était le concurrent de 4D.

avatar marc_os | 

https://lowendmac.com/lab/04/0115.html" rel="nofollow">Remarque historique :
Les premiers Macintosh avaient comme date de référence le 1er janvier 1904 et on peut continuer à les utiliser sans problème de date jusqu'en 2040 ! 🧟‍♂️

avatar FANREM | 

Rassurez vous, les anciens Macs sous Tiger ne seront plus en état de fonctionnement en 2038. Pas de quoi paniquer donc

avatar MisteriousGaga | 

Mais du coup, sur un vieux mac, (OS X Tiger dans l'article. Si il peut jamais dépasser 2037, ça ferait quoi, en 2040, de transférer un/des fichier/s créé la même année ?

Il pourra pas afficher la date de création ? Il va planter ?

avatar mathiasr | 

Dans les archives .zip (et donc les dérivés .jar), les dates des fichiers sont stockées sur 32 bits et seront donc confrontées au bug.

avatar pfx | 

Faut quand même pas oublié que beaucoup de travail a été fait en amont pour éviter le BUG de l’an 2000 !
Mise à jour ou remplacement de matériels et logiciels !

avatar berrald | 

“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.”
“Ce choix est pratique : en utilisant une valeur unique, tous les ordinateurs peuvent échanger entre eux, quel que soit leur fuseau horaire…”

Oui, mais premier janvier 1970 dans quel fuseau horaire ?
Je ne comprends pas comment ce système permet de s'affranchir du fuseau horaire…
Il faut bien convertir à un moment ou un autre, soit la date de départ (01/01/1970 à minuit), soit la date actuelle ?

avatar Nicolas Furno | 

@berrald

UTC.

avatar VanZoo | 

Vous avez sérieusement cru au bug de l'an 2000 ?! AH AH AH

avatar Azurea | 

Dire qu’ils ont fait un CD à l’époque pour contrer le bug (pour Windows).
Je l’ai gardé en souvenir !

avatar BeePotato | 

« on imaginait alors que tous les ordinateurs allaient planter le 1er janvier 2000 à minuit. »

Non, pas tous. :-)

https://www.youtube.com/watch?v=BwUQ1YtUpzw

Comme déjà indiqué par marc_os, la représentation des dates utilisée dans les versions classiques de MacOS était différente de la représentation Unix, et les vieux Mac ne sont du coup pas plus concernés par le bug de l’an 2038 qu’ils ne l’ont été par celui de l’an 2000.
Bon, ils n’auront pas un répit de bien longue durée, puisque le même problème se posera pour eux en 2040.

En tout cas, ce format de représentation des dates aura permis à toute une génération de savoir que le 1er janvier 1904 était un vendredi. :-)

avatar BeePotato | 

« À 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. »

Dans cette phrase, la seconde virgule est en trop (et la troisième aussi, du coup). Elle indique en effet que tous les ordinateurs suivent cette convention, ce qui n’est pas (et n’a jamais été) le cas.

avatar Jacalbert | 

Est-ce que Michel Drucker fera encore le décompte ? 😂🤣

avatar 2Bad | 

Quelle commande sur le terminal pour savoir le timestamp actuel?

2Bad

avatar Ranavision | 

J’ai essayé de rajouter un rappel dans mon agenda sur mon iPhone, mais il ne le sauvegarde pas, visiblement. Ca promet. 😇

Pages

CONNEXION UTILISATEUR