21
Linux / Le bug du 19 janvier 2038 à 3 h 14 min 8 s pourait impacter des trains / métros
« Dernier message par hwti le Aujourd'hui à 00:53:34 »
Pour les systèmes 64 bits, il me semble que seul le stockage de fichier est à risque.C'est plus compliqué que ça, dès qu'une date est stockée dans un fichier ou échangée (par exemple un protocole réseau), il y a un risque.
Par exemple s'il y a eu une définition historique avec un time_t 32 bits, alors le code peut :
- utiliser time_t, ce qui définit en fait un format différent selon la machine
- limiter explicitement à 32 bits, et se retrouver avec le bug de 2038 (et là il faut faire évoluer le format)
Il peut aussi y avoir du code qui manipule des dates dans des entiers 32 bits, soit pour des structures de données particulières, soit pour des implémentations d'un language interprêté (SQL, ...).
Par exemple sur https://en.wikipedia.org/wiki/Year_2038_problem :
Citer
As of MariaDB 11.5.1, released in May 2024, the data type TIMESTAMP and functions FROM_UNIXTIME(), UNIX_TIMESTAMP(), and CONVERT_TZ() handle unsigned 32-bit values on 64-bit versions of Linux, macOS, and Windows.Là il y a donc des base de données avec des dates explicitement stockées sur 32 bits, et une mise à jour assez récente de MariaDB permet de gérer les 32 bits comme non signés (comme alternative à passer en 64 bits, probablement en reconstruisant la base de données).
This extended the range to 2106-02-07 06:28:15 and allowed users to store such timestamp values in tables without changing the storage layout and thus staying fully compatible with existing user data.

Messages récents
Installation fibre SFR
Actus Orange
Incidents Free
snif