Bonjour,

J'utilise les sessions en base de données avec jSession. Tout fonctionne très bien. Cependant je désire stocker les sessions en temps universel coordonné (UTC). J'ai donc utilisé mon propre fichier DAO, en remplaçant les instructions « NOW() » par « UTC_TIMESTAMP() ». La modification ne pose pas de souci, et tout à l'air de fonctionner.

Mais cette modification peut-elle impacter certaines fonctions utiles de jSession ou du framework Jelix en général ?

Merci.

Bonjour,

De quelle instruction NOW() tu parles ? le dao d'origine n'en contient pas, et l'heure enregistrée est fournie par l'instruction date('Y-m-d H:i:s') dans le gestionnaire de session de jelix..

Ensuite, tu risques en effet d'avoir des soucis si ton serveur n'est pas calé sur l'heure UTC. En effet PHP effectue regulièrement un vidage des données des sessions expirées (en fonction des parametres dans le php.ini). Pour cela il demande au gestionnaire de session (donc ici celui de jelix), de détruire ces donneés, en lui donnant un temps de vie maximum. Donc si les datetimes stockées pour les sessions ne correspondent pas au fuseau horaire de la machine, il peut y avoir des sessions détruites prématurément ou en retard.

Si le serveur est calé sur UTC, alors il est inutile de spécifier UTC_TIMESTAMP puisque NOW ou date('Y-m-d H:i:s') renverra l'heure du serveur, donc UTC.

Pourquoi as tu vraiment besoin de stocker ces dates en UTC ?

Effectivement le DAO d'origine ne contient pas d'instruction « NOW() », je pensais être parti sur le DAO de Jelix, mais je l'ai recréé avec une commande « php jelix.php createdao ».

Donc j'ai ces propriétés suivantes :

<property name="creation" fieldname="sess_date_created" datatype="date" insertpattern="UTC_TIMESTAMP()" updatepattern="" required="true"/>
<property name="access" fieldname="ses_last_access" datatype="date" insertpattern="UTC_TIMESTAMP()" updatepattern="UTC_TIMESTAMP()" required="true"/>

Cette table « sessions » partage des entrées avec des applications écrites avec la technologie Adobe Flash. Nous avions choisi l'UTC, car il nous semblait plus facile de convertir directement sur le poste client depuis une heure UTC en heure locale quelque soit le pays.

Je suppose que c'est la méthode « jSession::daoGarbageCollector($maxlifetime) » qui pose problème ? Impossible de surcharger cette méthode dans le DAO ? Sinon il reste la possibilité de remplacer ce ramasse-miettes par une tâche exécutée par le programme cron. C'est le comportement par défaut sous Debian Linux pour les sessions stockées dans des fichiers qui sont effacés par la tâche « /etc/cron.d/php5 ».

Nous avions choisi l'UTC, car il nous semblait plus facile de convertir directement sur le poste client depuis une heure UTC en heure locale quelque soit le pays

pour convertir UTC vers une heure locale, il faut récupérer le decalage horaire et l'additionner à l'heure UTC. Si tu part d'une autre heure locale, ce n'est pas plus compliqué, il y a juste à faire une soustraction entre les deux decalages horaires, et l'additionner à l'heure locale. bref, une petite soustraction en plus dans la formule.

Avec jDatetime, c'est trivial, et je n'ai pas vérifié, mais si ça se trouve, le nouvel objet Datetime de php doit le faire très facilement aussi.

Sinon il reste la possibilité de remplacer ce ramasse-miettes par une tâche exécutée par le programme cron.

c'est ce que fait debian, effectivement, mais c'est une mesure en plus, histoire de faire le ménage (php detecte bien qu'une session est périmée, mais n'efface pas le fichier pour autant). bref, le problème reste.

un peu Hors sujet mais bon. ^^ Attention avec l'objet DateTime, il y a un bug très gênant sous windows, il y a des problèmes si on souhaite retourner le nombre de jours entre 2 date.