Le problème de l’an 2038 serait reporté à 2486 dans Linux 5.10

Pour des raisons de simplicité, d’optimisation et d’imagination – on imagine rarement qu’un programme que l’on a écrit soit utilisé pendant des décennies – les informaticiens ont toujours tendance à allouer trop peu de place pour définir les dates et les horaires.

C’est ainsi qu’il fallut un travail considérable de réécriture de code afin d’éviter que les ordinateurs ne comprennent pas les dates de l’an 2000 et postérieur.

Le problème se posera à nouveau dans Linux en 2038 : certaines dates sont calculées en comptant le temps depuis le 1er janvier 1970. Pour dépasser le 19 janvier 2038, il faudra un chiffre qui ne pourra plus tenir dans un nombre entier à 32 bits.

Avec Linux 5.6, des mesures sont entreprises par Arnd Bergmann afin de dépasser 2038 avec 32 bits – à condition que l’espace utilisateur soit compilé avec une structure time_t de 64 bits, au lieu de l’entier signé sur 32 bits, et que les interfaces d’appel système soient portées afin d’utiliser les appels systèmes time64 ajoutés à la version 5.1.

Il y a quelques jours, Darrick J. Wong a soumis le code pour que XFS soit compatible avec des horodatages jusqu’en 2486.

En supposant que la cadence habituelle de publication de nouvelles versions de Linux soit respectée, ces changements devraient être effectifs avant la fin de l’année, soit 17 ans avant que des problèmes ne soient apparus.

A priori, Windows ne devrait pas être concerné par le bogue de l’an 2038: le système de fichier NTFS utilise des dates sur 64 bis, ce qui est aussi le cas des compilateurs C les plus populaires de la plateforme.