Bug de l'an 2038

Un article de Wikipédia, l'encyclopédie libre.
Aller à : navigation, rechercher
Illustration du phénomène. La valeur décimale de la date deviendra négative à 03:14:08 UTC.

En informatique, le bug de l'an 2038 est un problème similaire au bug de l'an 2000 qui pourrait perturber le fonctionnement d'ordinateurs 32 bits le à h 14 min 7 s, temps universel[1].

Ce bug concerne potentiellement tous les systèmes d'exploitation et les programmes qui utilisent une représentation des dates en 32 bits. Il concerne les formats de fichier (tel ZIP), les systèmes de fichiers (comme le système de fichier FAT utilisé sur la plupart des clef USB et cartes flash), ou les systèmes d'exploitation à tous les niveaux (du noyau au langages de programmation), voir l'horloge matérielle elle-même.

Présentation[modifier | modifier le code]

Le problème concerne des logiciels qui utilisent la représentation POSIX du temps, dans lequel le temps est représenté comme un nombre de secondes écoulées depuis le à minuit (0 heure). Sur les ordinateurs 32 bits, la plupart des systèmes d'exploitation concernés représentent ce nombre comme un nombre entier signé de 32 bits, ce qui limite le nombre de secondes à 231 − 1, soit 2 147 483 647 secondes (01111111 11111111 11111111 11111111 en binaire). Ce nombre maximum sera atteint le à h 14 min 7 s (temps universel). Dans la seconde suivante, la représentation du temps « bouclera » (10000000 00000000 00000000 00000000 en binaire) et représentera −2 147 483 648 en complément à deux, et ainsi l'ordinateur affichera la date du .

Les logiciels concernés sont très nombreux car la norme POSIX, inspirée des systèmes UNIX, a été utilisée pour de nombreux programmes écrits en langage C pour de nombreux systèmes d'exploitation. Sur les systèmes d'exploitations de type Unix représentant le temps par un entier de 32 bits non signé (conforme à la norme POSIX), la date limite est située en 2106 et non en 2038. Ces systèmes d'exploitation sont toutefois minoritaires. Le passage à un timestamp sur 64 bits introduirait une nouvelle date butoir se situant à l'an 292 277 026 596 ap. J.-C. (soit environ 21 fois l'âge de l'univers) et résoudrait donc le problème, car les 64 bits permettraient à l'ordinateur de pousser la limite à 263 − 1 secondes.

Dans le domaine applicatif, le problème s'est révélé dès les années 2010 comme celui de l'an 2000 s'était révélé dès les années 1980 avec les échéanciers des plans à long terme (les tableurs utilisent depuis des dates soit glissantes, soit en format long).

Il n'existe pas de correctif simple et unique pour ce problème, car les timestamps sur 32 bits sont présents aussi dans plusieurs formats de fichiers actuels (par exemple le format ZIP). Un changement de représentation dans les ordinateurs rendrait inopérants les programmes exploitant l'actuelle équivalence entre la représentation interne et le format de fichiers. Beaucoup de travail sera donc nécessaire « en coulisses » pour que rien ou presque n'apparaisse en surface, ce qui avait déjà été le cas à l'approche de l'an 2000.

Système d'Exploitation[modifier | modifier le code]

Linux[modifier | modifier le code]

Les Systèmes Linux en 64 bits sont tous immunisés.

La version 3.17 du noyau Linux utilise une représentation interne des dates sur 64 bits[2],[3], ce qui prépare les autres adaptations nécessaires, au niveau des bibliothèques standard C puis des applications.

Android[modifier | modifier le code]

La version actuelle d'Android (Lolipop 5.1) à base de noyau Linux 3.10 n’incorpore aucune correction.

Windows[modifier | modifier le code]

En Visual C 8, le temps est codé sur 64 bits par défaut[4].

En Visual C 7.1, le développeur doit explicitement utiliser le temps en 64 bits[5].

Systèmes de fichier[modifier | modifier le code]

Ext2/3/4[modifier | modifier le code]

Les dates sont maintenant considérées comme non signées, permettant d'allonger de 68 ans leur durée de vie.

Les systèmes de fichier immunisés[modifier | modifier le code]

Les systèmes suivant codent leurs dates sur 64 bits :

Protocoles Réseau[modifier | modifier le code]

NTP[modifier | modifier le code]

NTP utilise une date de base au 1er janvier 1900 codée sur 64 bits dont 32 bits représentent les secondes. Ainsi il n'est pas sujet au bug de l'année 2038 mais au bug de l'année 2036.

NTPv4 utilise des champs "numéro d'ère" et "début d'ère" qui permettront d'outre-passer le bug.

Les versions suivantes du protocole utiliseront des dates codées sur 128 bit dont 64 bits représenteront les secondes.

Format de fichier[modifier | modifier le code]

  • ZIP code ses dates sur 32 bits. En considérant ces dates comme non signées, le format est valable 68 ans supplémentaires.

Notes et références[modifier | modifier le code]

Voir aussi[modifier | modifier le code]

Lien externe[modifier | modifier le code]