Bug de l'an 2038

Illustration du phénomène. La valeur décimale de la date deviendra négative à 3 h 14 min 8 s UTC, le 19 janvier 2038.

Le bug de l'an 2038, ou bogue de l'an 2038 (au Québec), aussi appelé Y2038 ou Epochalypse en anglais, est un bug informatique similaire au bug de l'an 2000, et dont les principales conséquences sont attendues le 19 janvier 2038 à 3 h 14 min 8 s, temps universel[1]. Les systèmes affectés par le bug considéreront alors être le 13 décembre 1901 à 20 h 45 min 52 s.

Ce bug concerne potentiellement tous les systèmes d'exploitation et les programmes qui mesurent le temps avec un nombre entier codé sur 32 bits. Il concerne les formats de fichier (tels que ZIP), les systèmes de fichiers (comme le système de fichier FAT32 utilisé sur la plupart des clés USB et cartes flash) et les systèmes d'exploitation à tous les niveaux (du noyau de système d'exploitation aux langages de programmation), voire l'horloge temps réel elle-même.

Présentation

Le problème concerne des logiciels qui utilisent la représentation POSIX du temps, dans laquelle le temps est représenté comme un nombre de secondes écoulées depuis le 1^er janvier 1970 à minuit (0 heure) temps universel. Sur les ordinateurs fonctionnant en 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 à 2^31 − 1, soit 2 147 483 647 secondes (01111111 11111111 11111111 11111111 en binaire)[2],[3]. Ce nombre maximum sera atteint le 19 janvier 2038 à 3 h 14 min 7 s (temps universel). La seconde suivante, écrite 10000000 00000000 00000000 00000000 en binaire, représente −2 147 483 648 en complément à deux, soit plus de 2 milliards de secondes avant 1970, le 13 décembre 1901 à 20 h 45 min 52 s pour être précis[4].

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 sur les échéanciers des plans à long terme (les tableurs utilisent depuis des dates soit glissantes, soit en format long)^[réf. nécessaire].

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 ceux 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.

Il n'existe pas de correctif simple et unique pour ce problème, car les horodatages sur 32 bits sont aussi présents 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.

Le passage à un horodatage sur 64 bits repousse la date butoir se situant au dimanche 4 décembre 292 277 026 596 ap. J.-C. à 15 h 30 min 8 s, soit environ 21 fois l'âge de l'Univers.

Systèmes concernés

Structures de données

De nombreuses structures de données qui sont en usage aujourd'hui ont des représentations de temps en format 32 bits, notamment, pour les plus connues :

• les systèmes de gestion de dossiers ;
• les formats de dossier binaires ;
• les bases de données ;
• certains langages de requête de base de données. (ex. : MySQL, qui utilise la fonction de type UNIX_TIMESTAMP() codée sur 32 bits).

Exemples de systèmes qui utilisent les formats de temps sur 32 bits :

• les systèmes COBOL conçus entre 1970 et 1990 ;
• les systèmes intégrés en utilisations dans les usines pour les sous-systèmes de contrôle et de surveillance de raffineries ;
• de nombreux systèmes informatiques en usage dans des organisations médicales et militaires.

Système d'exploitation

Linux

Les systèmes d’exploitation utilisant le noyau 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[5],[6],[7], ce qui prépare les autres adaptations nécessaires, au niveau des bibliothèques standard C puis des applications.

OpenBSD

OpenBSD est immunisé depuis sa version 5.5 de mai 2014[8].

Android

La version Marshmallow 6.0 d'Android à base de noyau Linux 3.10 n’incorpore aucune correction.

Windows

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

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

iOS

Les appareils de la marque Apple fonctionnant sous iOS fonctionnent en 64 bits.^[réf. nécessaire]

Systèmes de fichier

Ext2/3/4

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

Systèmes de fichier immunisés

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

• BTRFS
• NTFS

Protocoles réseau

NTP

Network Time Protocol (NTP) utilise une date de base au 1^er 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'outrepasser le bug.

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

Format de fichier

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

Solutions possibles

Il n’existe pas de solution universelle pour les problèmes qui se manifesteront en raison du bug de l'an 2038. N'importe quelle altération de la définition du type de variable utilisé pour dénoter le temps time_t enchaînerait des problèmes de compatibilité de code dans toutes les applications où la représentation de la date et du temps dépendent d'un système conçu de base pour fonctionner avec un nombre entier signé de 32 bits. Par exemple, le changement de time_t à un nombre entier non signé de 32 bits, ce qui permettrait l'utilisation des systèmes jusqu’à l'an 2106, causerait des complications pour les programmes qui manipulent des données qui ont des dates qui précèdent l'an 1970 car de telles dates seraient représentées par des nombres entiers négatifs. De plus, agrandir la variable time_t à un nombre entier de 64 bits dans les systèmes en utilisation courante produirait des changements incompatibles dans l'organisation des structures et de l'interface binaire de certaines fonctions.

La solution la plus simple proposée est de changer de système, en passant de 32 bits à 64 bits[4]. En effet, actuellement, la plupart des systèmes informatiques qui ont été conçus pour utiliser du matériel à 64 bits fonctionnent déjà avec des variables time_t de 64 bits.

Voir aussi

Articles connexes

• Dépassement d'entier
• Passage informatique à l'an 2000
• Panne informatique mondiale de juillet 2024
• Heure Unix
• Deep Impact, sonde spatiale qui fut victime d’un dysfonctionnement comparable au bug de l'an 2038[10].

Notes et références

1. (en) Sara Robinson, « Beyond 2000: Further Troubles Lurk in the Future of Computing », The New York Times,‎ 19 juillet 1999 (lire en ligne, consulté le 30 avril 2013).
2. Jean-Laurent Cassely, « 2.147.483.647 : pourquoi ce nombre peut tout faire buguer et rend fous les informaticiens », sur Slate.fr, 6 mai 2015 (consulté le 6 janvier 2018).
3. (en) Sandra Henry-Stocker, « Unix is turning 50. What does that mean? », sur Network World, 23 décembre 2019 (consulté le 13 janvier 2020)
4. Jean-Gabriel Ganascia, « Code informatique : vous avez craint le bug de l’an 2000, attendez de voir celui de 2038 », sur Atlantico.fr, 27 mai 2014 (consulté le 6 janvier 2018).
5. (en) Sean Michael Kerner, « Linux 3.17 is Getting ready for the Year 2038 », sur linuxplanet.com, 6 octobre 2014 (consulté le 6 janvier 2018).
6. (en) Jonathan Corbet, « Year 2038 preparations in 3.17 », sur LWN.net, 6 août 2014 (consulté le 6 janvier 2018).
7. Louis Adam, « Le noyau Linux survivra à l’année 2038 », ZDNet France,‎ 8 octobre 2014 (lire en ligne, consulté le 6 janvier 2018).
8. « OpenBSD 5.5 », sur openbsd.org (consulté le 11 décembre 2023).
9. (en) M3 Sweatt, « Another look at the year 2038 problem », Satisfy Me, sur blogs.msdn.microsoft.com, 21 avril 2008 (consulté le 6 janvier 2018).
10. (en) Malcolm Wallace, « Re: [tz] Deep Impact: wrong time zone? » [« Re: [tz] Deep Impact: mauvais fuseau horaire? »] [archive du 2 octobre 2013] [html] (consulté le 13 octobre 2018) : « Put another way, if you represented time as the number of tenths of a second since midnight on January 1, 2000, then you would hit 4294967296 tenths of a second on August 11, 2013[2]. 4294967296 is significant because it's 2^32, which is the smallest number that can't be represented as a 32-bit integer. Generally this will wrap around to 0 (as in calculating 4294967295 + 1 will give you 0). »

Annexes

Liens externes

• (en) « Year 2038 Bug What Can I Do As A Developer? », sur Prime Developers, 25 janvier 2015.
• Vincent Hermann, « Le kernel Linux 3.17 apporte de nombreuses améliorations », changements apportés par la version 3.17 du noyau Linux, sur Next INpact, 7 octobre 2014.
• (en) Jonathan Corbet, « 2038: only 21 years away », sur LWN.net, 15 mars 2017 (consulté le 13 janvier 2020).