Vous vous souvenez probablement de la panique entourant l’an 2000. Les médias se sont donnés à coeur joie en prédisant l’effondrement mondial lorsque l’horloge a sonné en 2000. Mais alors que de nombreux systèmes existants ont été corrigés à l’époque, un autre minuteur continue de s’écouler en arrière-plan d’une grande partie de l’Internet moderne. C’est ce qu’on appelle le problème de l’année 2038. Et cela est ancré dans la façon dont les langages de programmation C gèrent le temps.
La plupart des gens supposent que le problème concerne les années à deux chiffres, comme l’an 2000. Ce n’est pas le cas. Le problème central réside plus profondément dans le code. Plus précisément, comment les programmes C stockent les données de date.
La limite de 32 bits
Voici la réalité technique. La bibliothèque de temps standard en C utilise un entier signé de 4 octets pour suivre le temps. Cela fait 32 bits. Ce format définit « l’heure d’époque » comme commençant le 1er janvier 1970 à 00 :00 :00 UTC. Chaque seconde après ce moment est stockée sous forme d’un simple nombre.
Par exemple, l’horodatage « 919642718 » représente 919 millions de secondes après l’époque. Cela arrive le 21 février 1999. C’est pratique car soustraire un horodatage à un autre vous donne les secondes exactes entre deux événements. Les bibliothèques convertissent ensuite ces secondes en minutes, heures ou années.
Mais il y a un plafond dur.
Un entier signé de 32 bits a une valeur maximale de 2 147 483 647. Une fois que ce compteur atteint zéro seconde après le 1er janvier 1970, il redémarre.
Ce roulement a lieu le 19 janvier 2038.
Après cette date, l’entier déborde. Il devient un nombre négatif. Pour un système s’appuyant sur ce format, cette valeur négative est une date invalide. Il s’agit en fait d’un problème dans la matrice pour tout logiciel qui n’a pas été mis à jour.
Pourquoi c’est plus facile que l’an 2000
La bonne nouvelle ? Résoudre ce problème n’est pas aussi compliqué que les cauchemars du mainframe de la fin des années 90.
Au cours de l’an 2000, de nombreux systèmes ne standardisaient pas la manière dont ils stockaient les dates. Certains ont utilisé MM-JJ-AA. D’autres ont utilisé AA-MM-JJ. L’absence d’un format universel signifiait que les développeurs devaient rechercher le code dans chaque application et modifier manuellement la logique de date.
Le problème de l’année 2038 est plus propre.
La bibliothèque de temps standard encapsule l’ensemble du processus de chronométrage. Il définit ses propres types et fonctions. Ainsi, les programmes bien écrits peuvent simplement être recompilés. Les ingénieurs doivent simplement remplacer la bibliothèque par une version utilisant une taille d’octet plus grande.
Par exemple, passer d’un entier de 4 octets à un entier de 8 octets élargit considérablement la plage. Un entier signé de 8 octets peut compter bien au-delà de 2038 sans déborder. C’est une mise à jour logicielle. Il ne s’agit pas d’un remplacement matériel. Pas une réécriture de code. Un échange de bibliothèque.
Windows et Mac : minuteries différentes, problèmes différents
Tous les systèmes n’utilisent pas le format C 32 bits. Différents systèmes d’exploitation ont leurs propres bizarreries.
Windows NT, par exemple, utilise un entier de 64 bits. Il suit le temps par incréments de 100 nanosecondes. Mais le décompte commence à partir du 1er janvier 1601 et non de 1970. Cela repousse la date de débordement beaucoup plus loin. Windows atteindra probablement sa limite vers 2184.
Apple a adopté une approche différente. Selon la propre documentation d’Apple, macOS est structuré pour rester valable jusqu’en 29 940. Cela se passera dans environ 27 000 ans. Ainsi, si vous utilisez un Mac, vous n’avez pas à craindre que votre calendrier plante en 2038.
Qui d’autre est à risque ?
Les systèmes basés sur Unix constituent la principale préoccupation. Mais ils ne sont pas seuls.
Les systèmes embarqués sont également vulnérables. De nombreux appareils IoT, contrôleurs industriels et anciens serveurs de bases de données s’appuient sur le même format d’heure 32 bits. S’ils n’ont pas été mis à jour, ils commenceront à mal interpréter les dates après le 19 janvier 2038.
Les correctifs à court terme peuvent impliquer l’application de correctifs logiciels pour gérer correctement les valeurs de temps négatives. Mais c’est un pansement. La solution permanente nécessite une mise à niveau vers un format horaire 64 bits.
La question n’est pas de savoir si le code va être brisé. Il s’agit de savoir si les systèmes exécutant ce code seront mis à jour avant la fin du temps imparti.
La plupart des infrastructures sur lesquelles nous comptons évoluent déjà vers une gestion du temps 64 bits. Mais tout ne l’est pas. Anciens serveurs. Équipement industriel hérité. Une logique intégrée. Ce sont les maillons faibles.
Lorsque le 19 janvier 2038 arrivera, l’horloge atteindra sa limite. Pour certains systèmes, ce sera un non-événement. Pour d’autres, ce sera un arrêt difficile. Vous n’aurez pas beaucoup de temps pour corriger le code si vous attendez la dernière minute.
