J’utilisais un dolibarr sur un serveur A, que j’ai migré sur un serveur B avec une installation yunohost et réimport des config et base de données. Tout (ou presque) fonctionne très bien sur cette nouvelle installation en dehors de l’heure utilisateur que je n’arrive pas à récupérer correctement.
sur la page info dolibarr, voici ce j’ai pour la partie indiquant les réglages concernant les fuseaux horaires :
|Fuseau horaire MySQL (serveur) (database)|CEST|
|—|—|
|Fuseau horaire PHP (serveur)|+1 (+3600) Europe/Paris Heure d’été: Non (Oui en été)|
| => Heure PHP (serveur)|03/11/2021 15:01|
| => dol_print_date(0,dayhourtext)|01 Janvier 1970 01:00|
| => dol_get_first_day(1970,1,false)|-3600 (=> dol_print_date() or idate() of this value = 01/01/1970 00:00)|
| => dol_get_first_day(1970,1,true)|0 (=> dol_print_date() or idate() of this value = 01/01/1970 01:00)|
|Client Time Zone (user)|(+0) Heure d’été: Non|
| => Heure client (utilisateur)|03/11/2021 14:01|
La partie heure serveur est correct (y compris après le changement d’heure de ce week-end). Mais pas moyen d’avoir une heure correcte sur la partie « client time zone / heure client » qui était décalée de 2h jusqu’à ce week-end et plus que d’1h désormais.
sur le serveur (debian 10), timedatectrl renvoie ceci et le fuseau « Europe/Paris » a été renseigné dans les divers php.ini :
Local time: mer. 2021-11-03 15:04:52 CET
Universal time: mer. 2021-11-03 14:04:52 UTC
RTC time: mer. 2021-11-03 14:04:53
Time zone: Europe/Paris (CET, +0100)
System clock synchronized: yes
NTP service: inactive
RTC in local TZ: no
Après pas mal d’essais divers et variés je calle et n’arrive pas à trouver ce qui coince. Je suis actuellement en doli 14.0.3
j’ai tenté ma chance sur un forum yuno car ce décalage existait dès l’installation vierge, mais ils ne voient et m’ont plutôt renvoyé sur un réglage dans doli mais je n’arrive pas à trouver où.
Bonjour,
A tester un petit réglage dans Configuration / Divers : MAIN_SERVER_TZ ► If you can’t set the timezone of your PHP installation, set this constant. Better is to set it to UTC. In future, this constant will be forced to ‹ UTC › so PHP server timezone will not have effect anymore. Examples: Europe/Paris, auto.
@+
Bonsoir,
Alors j’avais testé il y a quelques semaines ce paramètre sans succès (j’avais l’impression qu’il ne changeait rien). MAIS, ce soir j’ai retesté plusieurs valeurs :
auto >> ras
Europe/Paris >> décalage de 2h
UTC > décalage de 1h
Europe/London >> l’heure utilisateur s’affiche correctement (bon de manière assez peu logique puisque je suis sur Europe/Paris dans Debian et PHP,
Et désormais les infos doli donnent ça :
|Fuseau horaire PHP (serveur)|+0 (unknown) Europe/London Heure d’été: Non (Oui en été)|
|—|—|
| => Heure PHP (serveur)|03/11/2021 21:08|
| => dol_print_date(0,dayhourtext)|01 Janvier 1970 01:00|
| => dol_get_first_day(1970,1,false)|-3600 (=> dol_print_date() or idate() of this value = 31/12/1969 23:00)|
| => dol_get_first_day(1970,1,true)|0 (=> dol_print_date() or idate() of this value = 01/01/1970 01:00)|
|Client Time Zone (user)|(+0) Heure d’été: Non|
| => Heure client (utilisateur)|03/11/2021 21:08|
bon en gros ça a l’air de le forcer à croire que le serveur est sur londre et ça me recale l’heure utilisateur. (j’imagine qu’au prochain changement d’heure ça risque de me redécaler). Je vais qd même laisser comme ça pour le moment car pour l’agenda et les heures de tickets c’est qd même plus pratique d’avoir la bonne heure, mais je suis preneur d’autres pistes??
Autre infos « bizarre » quand j’ai fais les modifs au niveau de l’interface, l’heure de modification de la variable, elle, s’affiche correctement à tous les coups (quelle que soit la valeur de MAIN_SERVER_TZ, quand je valide il m’affiche bien l’heure de mon fuseau horaire [enfin celui du serveur je pense qui est le même que celui de mon poste de travail]).
