Le 06/11/2012 21:39, Tony Chemit a écrit :
On Tue, 30 Oct 2012 10:05:26 +0100 Kevin Morin <morin@codelutin.com> wrote:
Salut,
je pense qu'il y a un gros soucis au niveau des dates : elles ne sont pas localisées... C'est particulièrement visible dans le header, c'est toujours la date CET qui s'affiche (j'ai demandé à quelqu'un au Japon pour vérifier). Je suppose donc que les dates de début et de fin de sondage sont aussi en CET... Je vais faire un ticket.
j'ai mis le ticket sur la prochaine version (1.5.6).
Kevin as-tu un peu de temps pour régler ça ? Y'apeut-être un changement à faire dans le modèle (donc une migration ?)
Si tu veux bien t'en occuper hésites pas à demander de l'aide ;) sinon je verrais ça en fin de semaine.
J'ai regardé d'où ça pouvait venir. Résultat : ça vient du widget datepicker qui renvoie une date sous la forme dd/mm/yy hh:mm, pas de timezone ni rien qui pourrait localiser l'utilisateur. Du coup le serveur parse la date telle quelle selon son heure à lui. Donc il faut changer la valeur de la date envoyée au submit du formulaire côté client, soit en mettant l'heure UTC (GMT) soit en renvoyant directement le timestamp soit en ajoutant le timezone offset à la fin de la date et le parser côté serveur (ex : " GMT +60" pour un offset d'1 heure). Je trouve l première solution pus simple. Pour la migration, il suffira de retirer 1h à toutes les dates de début et de fin dans la base. Pour l'affichage côté client, il faudra toujours ajouter l'offset de la timezone avant d'afficher la date. Tout ceci ne concerne que les dates de début et dates de fin, en aucun cas les choix de type date. Cette solution vous convient-elle ? Kevin