|
|
|
Publicité ' | |||||||||||||||||||||||
24/02/2011, 17h20
|
#1 |
|
Invité de passage
 Inscription : août 2008 Messages : 22  |
Datepicker et format
Bonjour à tous,
J'ai une différence de valeur suivant la méthode de retour utilisé ... Plus précisément, j'ai une heure de décalage ... Si je sélectionne 01-01-2010 dans le datepicker, voici ce que j'obtiens en retour en utilisant : getValues (date object) Fri Jan 01 2010 00:00:00 GMT+0100 (Paris,Madrid) et par submit du form et récup de la valeur (POST) dans mon script php 2009-12-31T23:00:00.000Z Une idée du problème ? |
|
00
|
|
26/02/2011, 13h47
|
#2 |
|
Expert Confirmé
   
  Urbaniste Inscription : juillet 2004 Messages : 1 419 |
ce n'est pas un problème mais une caractéristique.
les date sont en ISO 8601 GMT cela permet d'avoir une site international. en interne tous les échanges avec le serveur se font ainsi. le fichier locale coté client permet d'avoir un affichage dans la langue du pays. côté serveur soit tu gère les date en GMT et tu n'a rien à faire soit du les gère en français et tu dois appliquer le décalage à l'écriture et à la lecture. A+JYT |
|
|
00
|
|
26/02/2011, 21h46
|
#3 |
|
Invité de passage
Inscription : août 2008 Messages : 22 |
Merci pour ta réponse.
Mais j'ai du mal à comprendre ... Pourquoi un décalage alors que le client, en l'occurrence moi même, est basé en Belgique et le serveur en France ? Il faut que je me documente sur la gestion des dates en GMT !  C'est un fameux problème dans le cas d'une gestion d'appli de réservation de chambre d'hôtel car la date à prendre en compte est celle du pays de l'hôtel et non celle du client ... |
|
|
00
|
|
27/02/2011, 16h45
|
#4 |
|
Expert Confirmé
Urbaniste Inscription : juillet 2004 Messages : 1 419 |
la raison est simple
à priori lorsqu'on développe une lib comme ExtJS il est impossible de savoir quel décalage horaire existera à l'exécution entre le serveur et le client. impossible de savoir à priori quel fuseau pour le serveur et encore moins pour les clients qui peuvent en avoir des différents. du coup comment garantir que l'information échangé est cohérente. mon serveur est en France. j'ai un client au Japon et l'autre au Québec. le développer va devoir jongler avec pas mal de changement de dates pour être sur qu'aucune erreur de conversion ne sera introduite. il faut évidement compter en plus dan ce dialogue que le protocole ne transporte que du texte. la solution retenu est que durant le dialogue les dates seront toujours en ISO-8601 GMT pour le serveur cela devient relativement simple quelque soit son client et où qu'il soit toute date émise ou tout date reçue sera en ISO-8601 GMT dans mon exemple s'il travaille en interne avec le fuseau Français il fera une conversion GMT -> Paris lorsqu'il recevra une date du client et une conversion Paris -> GMT lorsqu'il enverra des données au client. pour le client lorsqu'il reçoit une date du serveur elle est en GMT il lui suffit de faire une conversion dans son fuseau horaire. pour le client au japon GMT -> Tokyo et lorsqu'il poste un formulaire Tokyo -> GMT pour le client au Québec même combat GMT -> Halifax à la réception et Halifax -> GMT à l'envoi Si on ne définit pas un fuseau pour les échanges il faut informer le client du décalage qu'il a avec le serveur pour qu'il puisse afficher les dates correctement. ou au contraire le serveur doit connaître le décalage de tous ses clients pour qu'il puisse lui faire le conversions nécessaires A+JYT |
|
|
10
|
|
27/02/2011, 22h08
|
#5 |
|
Invité de passage
Inscription : août 2008 Messages : 22 |
Merci !
Ca devient beaucoup plus clair pour moi. Je vais plancher un peu sur le sujet. Je reviendrai vers toi en cas de problème 
|
|
|
00
|
Copyright © 2000-2012 - www.developpez.com