Mise à jour GRR : souci sur l'heure des événements (affichage avec +2h).

Bonjour à tous,

Utilisateur de GRR (réservation de salles), suite à la mise à jour de la v2.4 vers la v3.4.1(g), j'ai quelques petits soucis sur les heures affichées (présentes dans la base de données GRR, table 'grr_entry', champs 'start_time' et 'end_time').

Alors que la configuration de l'heure sur le serveur qui héberge GRR est bonne, dans la conf (config.inc.php) d'origine de GRR (v2.x), il est mentionné :
putenv("TZ=posix/Etc/GMT+1");
$correct_heure_ete_hiver = 1;

Je pense que cette config n'est pas bonne, notamment pour : putenv("TZ=posix/Etc/GMT+1");

Avec GRR mis à jour en v3.4.1(g), je vois un affichage de TOUTES les réservations avec un décalage de +2 heures (début avril = heure d'été -> fuseau horaire Europe/Paris est en GMT+2).


Pour mieux comprendre la configuration de GRR, j'aimerais savoir :
1. comme la configuration de l'heure du serveur qui héberge GRR est bonne, est-ce que le paramêtre de configuration 'date_default_timezone_set('Etc/GMT+1');' (anciennement 'putenv("TZ=posix/Etc/GMT+1") est vraiment nécessaire à positionner, plutôt à la valeur 'date_default_timezone_set('Europe/Paris');' ?
2. ce paramètre peut-il ne pas être configuré (utilisatin du fuseau/horaire du serveur ?) ?
3. le paramètre '$correct_heure_ete_hiver' à qui sert-il réellement (utilie seulement si le paramêtre 'date_default_timezone_set('...')' est configuré ?) ?

Enfin :
4. le mieux ne serait pas de configurer :
//date_default_timezone_set('Europe/Paris');
$correct_heure_ete_hiver = 0;


De mon côté, à la vue du contenu des dates/heures dans la table 'grr_entry', je ne vois pas d'autre solution que de modifié TOUTEs les valeurs dates des champs 'start_time' et 'end_time' en leur enlevant 2 heures (7200 secondes) :
UPDATE grr_entry SET start_time = start_time - 7200;
UPDATE grr_entry SET end_time = end_time - 7200;

Est-ce bien la seule et bonne solution ?


Merci par avance pour vos retours.

Bien cordialement.

Bonjour,
le réglage 'date_default_timezone_set('Europe/Paris');' est à préférer si vos clients sont dans cette zone.
Quant au paramètre $correct_heure_ete_hiver, je ne suis pas sûr qu'il soit vraiment indispensable, mais je ne parierai pas sur la réponse.
Cordialement,
YN

Bonjour Yan.

Merci pour votre retour.

Qu'appelle-t-on réellement 'clients' (du service) ici, dans ce contexte ?
1. uniquement les périphériques utilisés pour ajouter/modifier/supprimer une réservation (accès contrôlé par login/mot de passe),
ou
2. est-ce TOUS les périphériques, ou qu'ils soient (géographiquement) ?

Pour 2., bien sûr que non, tous les clients ne sont pas dans la zone 'Europe/Paris' vu l'accès à l'applicatif, alors que pour 1. les ajouts/modifs/suppressions étant faites de façon vraiment très restreintes, oui, TOUS les clients 'modificateurs' sont dans la zone 'Europe/Paris'.

D'ou mon incompréhension de l'utilité du paramètre 'date_default_timezone_set(...)', mais aussi du paramètre '$correct_heure_ete_hiver'.

Mon sous-entendu était plutôt : ces deux paramètres ont-ils une (vrai) incidence (modification) sur l'heure/timestamp UNIX positionnée dans les champs 'start_time' et 'end_time' ou non (j'ai l'impression que oui, à la vue de mon problème de décalage de +2h sur TOUTES les heures affichées sur l'application par rapport aux heures - time stamp UNIX - présentes dans les champs 'start_time' et 'end_time' ---> peut être est-ce dû à un mauvais réglage de l'application GRR dans les versions précédentes, avant ma mise à jour) ?


Bien cordialement.
 

Bonjour,
je comprends très bien vos interrogations, et je les partage.
Ces paramètres ont une présence historique, apparues au fil du développement de GRR. Notamment le date_default_timezone_set introduit pour les utilisateurs hors métropole.
Pour ce qui est de $correct_heure_ete_hiver, je vois son utilité pour la gestion des jours de 23 ou 25 heures, lors du changement d'heure saisonnier.
Mais il est peut-être possible de faire autrement...
Cordialement,
YN