Voici maintenant plusieurs années qu’un bug a été détecté dans l’encodage du temps sur les systèmes de type Unix, notamment Linux, Mac OS, et autres systèmes d’exploitation compatibles POSIX. Sur Unix et les systèmes dérivés, le calcul du temps est effectué en fonction des secondes écoulées à partir du 1er janvier 1970 à 00:00:00 UTC (nommée également epoch). Un jour donnera par exemple 86 400 secondes et une année 31 536 000 — secondes. Et plus les années passeront, plus il faudra de nombres pour représenter les dates. Pour effectuer le décompte sur ces systèmes, lorsque la fonction time() est appelée, elle retourne un entier signé de type “time_t”. Si le système est 32 bits, la valeur retournée est un entier signé 32 bits et si le système est 64 bits, la valeur retournée est 64 bits.
Sur une machine 64 bits, les limites du type de données sont supérieures à 292 milliards d’années. À ce niveau donc, le monde technologique n’a pas de soucis à se faire (ce sera beaucoup plus que l’âge de notre planète ou l’estimation de son espérance de vie). Mais sur les systèmes 32 bits, le nombre de secondes total que la fonction peut retourner est 231 – 1, c’est-à-dire environ 136 ans. La date de référence étant le 1er janvier 1970 à 00:00:00 UTC, la date minimale représentable est le vendredi 13 décembre 1901 et la date maximale représentable est le mardi 19 janvier 2038 à 3 h 14 min 8 s. Lorsqu’il sera 3 h 14 min 8 s le 19 janvier 2038, le système passera au 13 décembre 1901 à la seconde suivante (également appelé le bug de l’an 2038 abrégé en anglais Y2038). Bien évidemment, ce ne sera pas la fin du monde, mais les systèmes 32 bits de la famille UNIX qui seront encore basés sur cet encodage seront fortement perturbés au point de ne plus pouvoir fonctionner correctement dans la mesure où un des éléments très importants sur les ordinateurs est le temps.
Voyant que 2038 approche et aucune solution n’a été publiée, Jon Corbet, chroniqueur de longue date du noyau Linux, a exprimé en 2015 son inquiétude par rapport à ce problème. Il déclara lors du sommet de collaboration de la fondation Linux à Santa Rosa en Californie qu’« il est temps de commencer à s’inquiéter ». Pour mieux se faire comprendre, il expliqua que « les systèmes basés sur Linux sont implémentés dans des voitures, dans la construction de systèmes de contrôle, dans les centrales électriques, et dans, qui sait combien, plusieurs autres endroits où ils y seront tout simplement placés et feront leur travail jusqu’à ce time_t vienne à manquer de bits. Et alors ils ne fonctionneront plus ».
L’équipe de Linux a pris depuis longtemps ce problème très au sérieux et vient d’intégrer un correctif dans la version 5.6 de Linux qui sera mis à la disposition du public. Dans son message de présentation des changements, Arnd Bergmann, qui fait partie de l’équipe de développement Linux rassure qu’il a parcouru toutes les instances de time_t et confirme qu’elles ont été remplacées par des alternatives sures. En conséquence, déclare-t-il, « Linux-5.6, ou mon backporting des correctifs vers 5,4 [1], devrait être la première version pouvant servir de base à un système 32 bits conçu pour fonctionner au-delà de l’année 2038 ». Toutefois, certains changements doivent être apportés à plusieurs niveaux :
- Tout l’espace utilisateur doit être compilé avec un time_t 64 bits, qui sera pris en charge dans les prochaines versions de musl-1.2 et glibc-2.32, ainsi que les entêtes de noyau installés de linux-5.6 ou supérieur ;
- les applications qui utilisent directement les interfaces d’appel système doivent être portées pour utiliser les appels système time64 ajoutés dans linux-5.1 à la place des appels système existants. Cela affecte la plupart des utilisateurs de futex () et seccomp () ainsi que les langages de programmation qui ont leur propre environnement d’exécution non basé sur libc ;
- les applications qui utilisent une copie privée des fichiers d’entête uapi du noyau ou de leur contenu peuvent nécessiter une mise à jour vers la version linux-5.6, en particulier pour sound/asound.h, xfs/xfs_fs.h, linux/input.h, linux/elfcore.h, linux/sockios.h, linux/timex.h et linux/ can / bcm.h ;
- quelques interfaces restantes ne peuvent pas être modifiées pour faire passer un time_t 64 bits de manière compatible. Elles doivent donc être configurées pour utiliser des heures CLOCK_MONOTONIC ou (avec un problème y2106) des horodatages 32 bits non signés. Plus important encore, cela affecte tous les utilisateurs de ‘struct input_event’ ;
- tous les problèmes y2038 qui sont présents sur les machines 64 bits s’appliquent également aux machines 32 bits. En particulier, cela affecte les systèmes de fichiers avec des horodatages sur disque utilisant des secondes 32 bits signés : ext4 avec de petits inodes de style ext3, ext2, xfs (à corriger bientôt) et ufs.