Date de réforme limitée au 19/01/2038

marcori · 2024-04-05 13:57:36

Bonjour,
Sur une installation de GLPI en version 10.0.14 sur Debian 12 avec PHP 8.2.16 et MariaDB 10.6.17.
Dans le cadre de l'inventaire d'équipements dans GLPI, je rencontre un problème avec les dates du cycle de vie du matériel.
Depuis un équipement inventorié, après avoir activé les "Informations financières et administratives", dans le menu "Gestion", si je modifie la date de réforme dans le cadre "Cycle de vie du matériel", alors je ne peux pas indiquer une date supérieure au 19/01/2038 (format saisi = "2038-01-20").
Quelle serait l'origine de ce dysfonctionnement et comment puis-je y remédier ?
Merci d'avance de vos réponses.
Marc-Henri

marcori · 2024-04-05 22:12:41

Il faut croire que mon installation de GLPI hébergée par O2Switch soit sensible au bug 2K38 (https://fr.wikipedia.org/wiki/Bug_de_l%27an_2038), et il semble que ce dysfonctionnement lié à la taille d'un TIMESTAMP ait été corrigé avec la version 11.5 de MariaDB : https://mariadb.com/kb/en/changes-impro … iadb-11-5/

cconard96 · 2024-04-05 23:23:00

Autant que je sache, MySQL ne prend toujours pas en charge les horodatages 64 bits. Je ne sais pas comment cela sera géré du côté GLPI à l'avenir s'il n'est pas géré à la fois par MySQL et MariaDB.

marcori · 2024-04-22 18:02:33

MariaDB propose aussi le format DATETIME :
https://mariadb.com/kb/en/datetime/

Ne serait-ce pas une bonne alternative au format TIMESTAMP utilisé par GLPI :
https://mariadb.com/kb/en/timestamp/

D'après la documentation, les deux formats ont une précision à la microseconde.

Je lis la documentation de MySQL :
https://dev.mysql.com/doc/refman/8.0/en … types.html
https://dev.mysql.com/doc/refman/8.0/en/datetime.html

Je ne comprends pas bien pourquoi GLPI a utilisé le format TIMESTAMP pour qualifier les dates dans la base de données puisque son range va de 1970-01-01 00:00:01 UTC à 2038-01-19 03:14:07 UTC alors même que le format DATETIME dispose d'un range qui va de 1000-01-01 00:00:00 à 9999-12-31 23:59:59...

Est-il possible de convertir dans le fichier de création initial de la BDD (install/mysql/glpi-empty.sql ?) les champs de type timestamp vers un type datetime ?
Quelle incidence par la suite, tant sur les fonctionnalités que sur les performances ?

cconard96 · 2024-04-23 15:46:33

Nous venons de passer de l'utilisation de DATETIME à TIMESTAMP dans GLPI .

https://github.com/glpi-project/glpi/pull/5539

Il était censé faciliter la gestion des fuseaux horaires en indiquant à la base de données le fuseau horaire défini par l'utilisateur actuel, puis en laissant la base de données renvoyer les dates et les heures dans le fuseau horaire souhaité pour nous.

La migration vers DATETIME avec une prise en charge appropriée du fuseau horaire cette fois sera une tâche considérable. Je ne pense pas que ce soit prévu pour la prochaine version principale de GLPI.

marcori · 2024-04-29 18:14:21

Diantre !
Et donc, que peut-on prévoir pour pallier le bug de 2038 puisque j'ai des utilisateurs qui commencent à saisir des éléments d'inventaire dont la date de fin de garantie dépasse 2038 ?

cconard96 · 2024-04-29 20:02:48

Si vous utilisez déjà MariaDB, la solution serait de mettre à jour vers MariaDB 11.5. Je n'ai aucune information sur si/comment cela sera géré du côté de GLPI pour le moment.

Forum GLPI-Project

Announcement

#1 2024-04-05 13:57:36

Date de réforme limitée au 19/01/2038

#2 2024-04-05 22:12:41

Re: Date de réforme limitée au 19/01/2038

#3 2024-04-05 23:23:00

Re: Date de réforme limitée au 19/01/2038

#4 2024-04-22 18:02:33

Re: Date de réforme limitée au 19/01/2038

#5 2024-04-23 15:46:33

Re: Date de réforme limitée au 19/01/2038

#6 2024-04-29 18:14:21

Re: Date de réforme limitée au 19/01/2038

#7 2024-04-29 20:02:48

Re: Date de réforme limitée au 19/01/2038

Board footer