// We use dol_tz_string first because it contains dst.
$default_timezone=(empty($_SESSION["dol_tz_string"])?@date_default_timezone_get():$_SESSION["dol_tz_string"]);
try {
$localtz = new DateTimeZone($default_timezone);
}
catch(Exception $e)
{
dol_syslog("Warning dol_tz_string contains an invalid value ".$_SESSION["dol_tz_string"], LOG_WARNING);
$default_timezone=@date_default_timezone_get();
}
vous rajoutez dans le catch ce qui plante dans le try…
J’ai essayé et chez moi pas de probléme. Si cette fonction était buggé ce n’estpas que projet qui poserais probléme mais tout ecran de dolibar qui joue avec des dates.
Pouvez vous nous donner un cas de test : Création du tache vacec la valeur des différent attributs ? Avez vous ajouté des attribut suplémetaire sur les taches ?
Je penche plus pour un probléme de timeZone du serveur (cf conf apache/php/mysql) ou d’une date qui n’existe aps que vous avez mis dans l’interface.
En fait le problème vient de google chrome qui renvoie un timezone « Paris/_Europe ». Je n’ai pas de problème avec Firefox et IE il renvoie une valeur vide.
Je le vois dans Outils Système>Infos Dolibarr >Fuseau horaire client (utilisateur)
aramètres de localisation Valeur
Variable HTTP_ACCEPT_LANGUAGE fr-FR,fr;q=0.8,en-US;q=0.6,en;q=0.4
Langue utilisateur actuelle fr_FR
Séparateur de milliers Space
Séparateur décimal ,
=> price2num(1233.56+1) 1234.56
=> price2num(‹ 1Space234,56 ›) 1
=> price2num(‹ 1 234.56 ›) 1234.56
=> price(1234.56) 1 234,56
Fuseau horaire PHP (serveur)
+0 (+0) UTC Heure d’été: Non
=> Heure PHP (serveur) 31/08/2014 13:31
=> dol_print_date(0,« dayhourtext ») 01 Janvier 1970 00:00
=> dol_get_first_day(1970,1,false) 0 (=> 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 00:00)
Fuseau horaire MySql (serveur) (database)
Paris, Madrid (heure d
Fuseau horaire client (utilisateur) +2 (+7200) Paris/_Madrid Heure d’été: Oui
=> Heure client (utilisateur) 31/08/2014 15:31
File encoding (php.ini unicode.filesystem_encoding)
=> File encoding iso-8859-1
Paris/_Madrid est un timezone invalide. Néanmoins je ne sais pas modifier cette valeur dans chrome.
J’ai comme je l’ai décrit au dessus exactement le même problème. Cela fonctionne sous Firefox et IE mais pas avec chrome. Pour chrome pour l’instant seule ma bidouille fonctionne mais je ne suis pas sur des effets secondaires.
Bonjour je remonte ce topic, j’ai exactement le même pb en ajoutant la ligne ci-dessus, cela fonctionne bien, mais avez vous une solution native ?
Merci d’avance
Je remonte cette file car j’ai détecté un problème sur la 3.7 avec la timezone qui semble corrigé avec sur la 3.8 (par l’ajout d’un script javascript)
la timezone par défaut « Paris/_Europe » fait planter la fonction alors qu’avec « Berlin/Europe » cela fonctionne (ce que retourne la 3.8
lors de la création d’une tache, il y a toujours 2 heures d’ajouté (si on laisse à 00:00 on l’heure de début de tache passe à 2:00
D’après mes test; la correction donnée ici corrige le soucis
Je rencontre un petit soucis avec la version Dolibarr 3.9.0.
Lorsque je donne une date et une heure de début de tache ( exemple le 11 04 2016 à 15 h 00 ), après validation, je remarque que l’heure de départ (que je viens d’indiquer à 15 ) est repassée comme par magie à 08H00…