J'ai un petit soucis, à savoir que pour un site sur lequel je travaille,
l'horodatage est *très important* et le serveur de dev et le serveru de
prod ne sont pas au même endroit (l'un en france, l'autre aux US).
Forcémment, quand je passe le site "fonctionnel" en prod, je me prend 6h
dans la vue.
Je voudrais éviter de reprendre toutes mes fonctions date() pour leur
rajouter 6h, y'a t'il un moyen de dire à mes scripts que je veux qu'il
compte le décalage horaire en plus?
Merci d'avance
--
Découvrez Original War: http://www.original-war.org
Humour: http://www.chatfou.com
Tchattez en liberté: http://www.crazy-irc.net
les clients doivent pouvoir juger de la validite d'une information rapidement. l'affichage dans leur timezone est une facilite. la c'est du confort.
on ne doit pas compter sur javascript, ok. mais on ne doit pas compter sur le fait que chacun dans le monde connaisse sa timezone (manque de curiosite personnelle sans doute). ou le decalage entre son pays et un autre (ce qui implique de connaitre plusieurs timezones et quels sont les pays qui y sont)
voila pour mieux cerner la "problematique"
plus qu'un confort, c'est une necessite :
les clients doivent pouvoir juger de la validite d'une information
rapidement. l'affichage dans leur timezone est une facilite. la c'est
du confort.
on ne doit pas compter sur javascript, ok. mais on ne doit pas compter
sur le fait que chacun dans le monde connaisse sa timezone (manque de
curiosite personnelle sans doute). ou le decalage entre son pays et un
autre (ce qui implique de connaitre plusieurs timezones et quels sont
les pays qui y sont)
les clients doivent pouvoir juger de la validite d'une information rapidement. l'affichage dans leur timezone est une facilite. la c'est du confort.
on ne doit pas compter sur javascript, ok. mais on ne doit pas compter sur le fait que chacun dans le monde connaisse sa timezone (manque de curiosite personnelle sans doute). ou le decalage entre son pays et un autre (ce qui implique de connaitre plusieurs timezones et quels sont les pays qui y sont)
voila pour mieux cerner la "problematique"
ftc
Pourquoi le faire en javascript ? Ca peut être fait directement dans l'application qui est en train de calculer la page, voire même très probablement fait dès la récupération de l'information depuis la base de données.
Pour que ça puisse être fait côté serveur, il faut connaitre le fuseau horraire du client.
Parce que le faire en javascript, vous pouvez sans connaître le fuseau horaire du client ?
Bien sûr, c'est d'une simplicité enfantine, on récupère le fuseau horaire très simplement en javascript avec l'objet Date.
Le fuseau horaire peut être un paramètre du compte client, stocké sur le serveur et connu dès qu'il y a authentification. Ou choisi par le client à la connexion sur le site (cas du client itinérant qui change souvent de fuseaux horaires)
Je n'ai pas dit le contraire, mais il peut aussi y avoir une utilisation sans authentification du client.
D'autre part, il n'y a pas que le problème du calcul de la date dans le fuseau local : si on veut faire proprement de l'internationalisation, il y a le problème du format d'affichage, une date ne s'écrit pas de la même façon partout dans le monde.
Ca, c'est un autre sujet, il est facile de récupérer la langue dans les en-têtes HTTP.
Facile, non. Possible, oui, grâce à la négociation de contenu en HTTP. Ca impose cependant que le navigateur soit correctement configuré, ce qui est rarement le cas à ce sujet.
C'est vrai qu'en France on règle souvent son navigateur sur en_US ou fr_CA.
Pourquoi le faire en javascript ? Ca peut être fait directement dans
l'application qui est en train de calculer la page, voire même très
probablement fait dès la récupération de l'information depuis la base
de données.
Pour que ça puisse être fait côté serveur, il faut connaitre le fuseau
horraire du client.
Parce que le faire en javascript, vous pouvez sans connaître le fuseau
horaire du client ?
Bien sûr, c'est d'une simplicité enfantine, on récupère le fuseau
horaire très simplement en javascript avec l'objet Date.
Le fuseau horaire peut être un paramètre du compte client, stocké sur le
serveur et connu dès qu'il y a authentification. Ou choisi par le client
à la connexion sur le site (cas du client itinérant qui change souvent de
fuseaux horaires)
Je n'ai pas dit le contraire, mais il peut aussi y avoir une utilisation
sans authentification du client.
D'autre part, il n'y a pas que le problème du calcul de la date dans
le fuseau local : si on veut faire proprement de
l'internationalisation, il y a le problème du format d'affichage, une
date ne s'écrit pas de la même façon partout dans le monde.
Ca, c'est un autre sujet, il est facile de récupérer la langue dans les
en-têtes HTTP.
Facile, non.
Possible, oui, grâce à la négociation de contenu en HTTP. Ca impose
cependant que le navigateur soit correctement configuré, ce qui est
rarement le cas à ce sujet.
C'est vrai qu'en France on règle souvent son navigateur sur en_US ou fr_CA.
Pourquoi le faire en javascript ? Ca peut être fait directement dans l'application qui est en train de calculer la page, voire même très probablement fait dès la récupération de l'information depuis la base de données.
Pour que ça puisse être fait côté serveur, il faut connaitre le fuseau horraire du client.
Parce que le faire en javascript, vous pouvez sans connaître le fuseau horaire du client ?
Bien sûr, c'est d'une simplicité enfantine, on récupère le fuseau horaire très simplement en javascript avec l'objet Date.
Le fuseau horaire peut être un paramètre du compte client, stocké sur le serveur et connu dès qu'il y a authentification. Ou choisi par le client à la connexion sur le site (cas du client itinérant qui change souvent de fuseaux horaires)
Je n'ai pas dit le contraire, mais il peut aussi y avoir une utilisation sans authentification du client.
D'autre part, il n'y a pas que le problème du calcul de la date dans le fuseau local : si on veut faire proprement de l'internationalisation, il y a le problème du format d'affichage, une date ne s'écrit pas de la même façon partout dans le monde.
Ca, c'est un autre sujet, il est facile de récupérer la langue dans les en-têtes HTTP.
Facile, non. Possible, oui, grâce à la négociation de contenu en HTTP. Ca impose cependant que le navigateur soit correctement configuré, ce qui est rarement le cas à ce sujet.
C'est vrai qu'en France on règle souvent son navigateur sur en_US ou fr_CA.
Patrick Mevzek
Cependant, il parait plus sain d'utiliser le fuseau GMT quand on stocke
dans la base de données, et de passer de GMT au fuseau qui vous intéresse au niveau applicatif.
C'est bien là que réside le problème : Comment connaître le fuseau horaire du client ? Tu n'apportes aucune réponse à ce sujet.
On lui demande explicitement: 1) soit s'il y a authentification, au moment où il créé son compte (il faudra juste penser au fait qu'il peut changer dans le temps quand même, donc l'utilisateur doit pouvoir le modifier) 2) soit en proposant une liste déroulante avec les choix, qui entraîne le stockage dans un cookie, si on ne veut absolument rien regarder du côté serveur.
C'est en gros le même principe que pour le choix d'une langue, puisque même avec la négociation de contenu, cela ne suffit pas, compte-tenu de la non-configuration de la majorité des navigateurs. D'ailleurs on pourrait même tenter de déterminer les fuseaux horaires pertinents en fonction de la locale renvoyée par le client, mais c'est vraiment trop hasardeux.
Vous pouvez saupoudrer de javascript si vous voulez (mais pour un tel besoin, personnellement, je ne le ferais pas), pour récupérer la valeur automatiquement (cf objet Date et méthode getTimezoneOffset()), et par exemple sélectionner par défaut la bonne entrée dans la liste déroulante (tout en laissant le libre arbitre de l'utilisateur).
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Cependant, il parait plus sain d'utiliser le fuseau GMT quand on
stocke
dans la base de données, et de passer de GMT au fuseau qui vous
intéresse au niveau applicatif.
C'est bien là que réside le problème : Comment connaître le fuseau
horaire du client ? Tu n'apportes aucune réponse à ce sujet.
On lui demande explicitement:
1) soit s'il y a authentification, au moment où il créé son compte
(il faudra juste penser au fait qu'il peut changer dans le temps quand
même, donc l'utilisateur doit pouvoir le modifier)
2) soit en proposant une liste déroulante avec les choix, qui entraîne le
stockage dans un cookie, si on ne veut absolument rien regarder du côté
serveur.
C'est en gros le même principe que pour le choix d'une langue, puisque
même avec la négociation de contenu, cela ne suffit pas, compte-tenu de
la non-configuration de la majorité des navigateurs.
D'ailleurs on pourrait même tenter de déterminer les fuseaux horaires
pertinents en fonction de la locale renvoyée par le client, mais c'est
vraiment trop hasardeux.
Vous pouvez saupoudrer de javascript si vous voulez (mais pour un tel
besoin, personnellement, je ne le ferais pas), pour récupérer la valeur
automatiquement (cf objet Date et méthode getTimezoneOffset()),
et par exemple sélectionner par défaut la bonne entrée
dans la liste déroulante (tout en laissant le libre arbitre de
l'utilisateur).
--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Cependant, il parait plus sain d'utiliser le fuseau GMT quand on stocke
dans la base de données, et de passer de GMT au fuseau qui vous intéresse au niveau applicatif.
C'est bien là que réside le problème : Comment connaître le fuseau horaire du client ? Tu n'apportes aucune réponse à ce sujet.
On lui demande explicitement: 1) soit s'il y a authentification, au moment où il créé son compte (il faudra juste penser au fait qu'il peut changer dans le temps quand même, donc l'utilisateur doit pouvoir le modifier) 2) soit en proposant une liste déroulante avec les choix, qui entraîne le stockage dans un cookie, si on ne veut absolument rien regarder du côté serveur.
C'est en gros le même principe que pour le choix d'une langue, puisque même avec la négociation de contenu, cela ne suffit pas, compte-tenu de la non-configuration de la majorité des navigateurs. D'ailleurs on pourrait même tenter de déterminer les fuseaux horaires pertinents en fonction de la locale renvoyée par le client, mais c'est vraiment trop hasardeux.
Vous pouvez saupoudrer de javascript si vous voulez (mais pour un tel besoin, personnellement, je ne le ferais pas), pour récupérer la valeur automatiquement (cf objet Date et méthode getTimezoneOffset()), et par exemple sélectionner par défaut la bonne entrée dans la liste déroulante (tout en laissant le libre arbitre de l'utilisateur).
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Guillaume Bouchard
julian wrote:
plus qu'un confort, c'est une necessite :
les clients doivent pouvoir juger de la validite d'une information rapidement. l'affichage dans leur timezone est une facilite. la c'est du confort.
Ok, je suis d'accord avec ce concept.
on ne doit pas compter sur javascript, ok. mais on ne doit pas compter sur le fait que chacun dans le monde connaisse sa timezone (manque de curiosite personnelle sans doute). ou le decalage entre son pays et un autre (ce qui implique de connaitre plusieurs timezones et quels sont les pays qui y sont)
Hum, dans cze cas là tu vas me dire que ces personne ne conaissent pas leurs timezone mais ont l'heure correctement configurée sur leur machine ?
Si je me rapel bien mes souvenirs de Windows, il y a un menu déroulant extremement precit pour les timezone, ces personnes l'on forcement remplie un jour, ils doivent connaitre leur timezone. Au pire lors de l'inscription, ils apprendront. Non ?
Je conçoit que ce n'est pas une solution parfaite, mais y en a-t-il une meilleur ?
-- Guillaume.
julian wrote:
plus qu'un confort, c'est une necessite :
les clients doivent pouvoir juger de la validite d'une information
rapidement. l'affichage dans leur timezone est une facilite. la c'est
du confort.
Ok, je suis d'accord avec ce concept.
on ne doit pas compter sur javascript, ok. mais on ne doit pas compter
sur le fait que chacun dans le monde connaisse sa timezone (manque de
curiosite personnelle sans doute). ou le decalage entre son pays et un
autre (ce qui implique de connaitre plusieurs timezones et quels sont
les pays qui y sont)
Hum, dans cze cas là tu vas me dire que ces personne ne conaissent pas
leurs timezone mais ont l'heure correctement configurée sur leur machine ?
Si je me rapel bien mes souvenirs de Windows, il y a un menu déroulant
extremement precit pour les timezone, ces personnes l'on forcement
remplie un jour, ils doivent connaitre leur timezone. Au pire lors de
l'inscription, ils apprendront. Non ?
Je conçoit que ce n'est pas une solution parfaite, mais y en a-t-il une
meilleur ?
les clients doivent pouvoir juger de la validite d'une information rapidement. l'affichage dans leur timezone est une facilite. la c'est du confort.
Ok, je suis d'accord avec ce concept.
on ne doit pas compter sur javascript, ok. mais on ne doit pas compter sur le fait que chacun dans le monde connaisse sa timezone (manque de curiosite personnelle sans doute). ou le decalage entre son pays et un autre (ce qui implique de connaitre plusieurs timezones et quels sont les pays qui y sont)
Hum, dans cze cas là tu vas me dire que ces personne ne conaissent pas leurs timezone mais ont l'heure correctement configurée sur leur machine ?
Si je me rapel bien mes souvenirs de Windows, il y a un menu déroulant extremement precit pour les timezone, ces personnes l'on forcement remplie un jour, ils doivent connaitre leur timezone. Au pire lors de l'inscription, ils apprendront. Non ?
Je conçoit que ce n'est pas une solution parfaite, mais y en a-t-il une meilleur ?
-- Guillaume.
Patrick Mevzek
Pour que ça puisse être fait côté serveur, il faut connaitre le fuseau horraire du client.
Parce que le faire en javascript, vous pouvez sans connaître le fuseau horaire du client ?
Bien sûr, c'est d'une simplicité enfantine, on récupère le fuseau horaire très simplement en javascript avec l'objet Date.
(J'avais un doute, mais maintenant je crois vraiment que vous me prenez pour un idiot. La discussion risque donc de devenir difficile...)
Quoi qu'on fasse il faut faire quelque chose pour récupérer le fuseau horaire. Ce n'est pas plus complexe d'appeler Date que de faire une liste déroulante et de récupérer le choix de l'utilisateur du côté du serveur. Et le faire sur le serveur cela a tout un tas d'avantages.
Le fuseau horaire peut être un paramètre du compte client, stocké sur le serveur et connu dès qu'il y a authentification. Ou choisi par le client à la connexion sur le site (cas du client itinérant qui change souvent de fuseaux horaires)
Je n'ai pas dit le contraire, mais il peut aussi y avoir une utilisation sans authentification du client.
Ce qui n'empêche pas de mettre une liste déroulante pour laisser le client choisir et stocker la valeur dans un cookie.
Possible, oui, grâce à la négociation de contenu en HTTP. Ca impose cependant que le navigateur soit correctement configuré, ce qui est rarement le cas à ce sujet.
C'est vrai qu'en France on règle souvent son navigateur sur en_US ou fr_CA.
En France, comme ailleurs, on règle *rarement* son navigateur correctement. Ca se voit très facilement dès qu'on gère un site qui fait de la négociation de contenu...
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Pour que ça puisse être fait côté serveur, il faut connaitre le fuseau
horraire du client.
Parce que le faire en javascript, vous pouvez sans connaître le fuseau
horaire du client ?
Bien sûr, c'est d'une simplicité enfantine, on récupère le fuseau
horaire très simplement en javascript avec l'objet Date.
(J'avais un doute, mais maintenant je crois vraiment que vous me prenez
pour un idiot. La discussion risque donc de devenir difficile...)
Quoi qu'on fasse il faut faire quelque chose pour récupérer le fuseau
horaire. Ce n'est pas plus complexe d'appeler Date que de faire une liste
déroulante et de récupérer le choix de l'utilisateur du côté du serveur.
Et le faire sur le serveur cela a tout un tas d'avantages.
Le fuseau horaire peut être un paramètre du compte client, stocké sur
le serveur et connu dès qu'il y a authentification. Ou choisi par le
client à la connexion sur le site (cas du client itinérant qui change
souvent de fuseaux horaires)
Je n'ai pas dit le contraire, mais il peut aussi y avoir une utilisation
sans authentification du client.
Ce qui n'empêche pas de mettre une liste déroulante pour laisser le
client choisir et stocker la valeur dans un cookie.
Possible, oui, grâce à la négociation de contenu en HTTP. Ca impose
cependant que le navigateur soit correctement configuré, ce qui est
rarement le cas à ce sujet.
C'est vrai qu'en France on règle souvent son navigateur sur en_US ou
fr_CA.
En France, comme ailleurs, on règle *rarement* son navigateur
correctement.
Ca se voit très facilement dès qu'on gère un site qui fait de la
négociation de contenu...
--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Pour que ça puisse être fait côté serveur, il faut connaitre le fuseau horraire du client.
Parce que le faire en javascript, vous pouvez sans connaître le fuseau horaire du client ?
Bien sûr, c'est d'une simplicité enfantine, on récupère le fuseau horaire très simplement en javascript avec l'objet Date.
(J'avais un doute, mais maintenant je crois vraiment que vous me prenez pour un idiot. La discussion risque donc de devenir difficile...)
Quoi qu'on fasse il faut faire quelque chose pour récupérer le fuseau horaire. Ce n'est pas plus complexe d'appeler Date que de faire une liste déroulante et de récupérer le choix de l'utilisateur du côté du serveur. Et le faire sur le serveur cela a tout un tas d'avantages.
Le fuseau horaire peut être un paramètre du compte client, stocké sur le serveur et connu dès qu'il y a authentification. Ou choisi par le client à la connexion sur le site (cas du client itinérant qui change souvent de fuseaux horaires)
Je n'ai pas dit le contraire, mais il peut aussi y avoir une utilisation sans authentification du client.
Ce qui n'empêche pas de mettre une liste déroulante pour laisser le client choisir et stocker la valeur dans un cookie.
Possible, oui, grâce à la négociation de contenu en HTTP. Ca impose cependant que le navigateur soit correctement configuré, ce qui est rarement le cas à ce sujet.
C'est vrai qu'en France on règle souvent son navigateur sur en_US ou fr_CA.
En France, comme ailleurs, on règle *rarement* son navigateur correctement. Ca se voit très facilement dès qu'on gère un site qui fait de la négociation de contenu...
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Patrick Mevzek
on ne doit pas compter sur javascript, ok. mais on ne doit pas compter sur le fait que chacun dans le monde connaisse sa timezone (manque de curiosite personnelle sans doute).
Dans les applications bien faites, on ne présente pas de +0100 +0200 +0300 etc... mais des chaines sous la forme Europe/France ou avec des villes, et on demande à l'utilisateur de choisir dans la liste le pays (quand il n'y a qu'un fuseau horaire) ou la ville la plus proche. Cela répond à 99.99% des cas de figures, et les autres en général ils connaissent leur décalage, donc sauront se débrouiller.
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
on ne doit pas compter sur javascript, ok. mais on ne doit pas compter
sur le fait que chacun dans le monde connaisse sa timezone (manque de
curiosite personnelle sans doute).
Dans les applications bien faites, on ne présente pas de +0100 +0200
+0300 etc... mais des chaines sous la forme Europe/France ou avec des
villes, et on demande à l'utilisateur de choisir dans la liste le pays
(quand il n'y a qu'un fuseau horaire) ou la ville la plus proche.
Cela répond à 99.99% des cas de figures, et les autres en général ils
connaissent leur décalage, donc sauront se débrouiller.
--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
on ne doit pas compter sur javascript, ok. mais on ne doit pas compter sur le fait que chacun dans le monde connaisse sa timezone (manque de curiosite personnelle sans doute).
Dans les applications bien faites, on ne présente pas de +0100 +0200 +0300 etc... mais des chaines sous la forme Europe/France ou avec des villes, et on demande à l'utilisateur de choisir dans la liste le pays (quand il n'y a qu'un fuseau horaire) ou la ville la plus proche. Cela répond à 99.99% des cas de figures, et les autres en général ils connaissent leur décalage, donc sauront se débrouiller.
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
ftc
Quoi qu'on fasse il faut faire quelque chose pour récupérer le fuseau horaire. Ce n'est pas plus complexe d'appeler Date que de faire une liste déroulante et de récupérer le choix de l'utilisateur du côté du serveur. Et le faire sur le serveur cela a tout un tas d'avantages.
La, vous demandez une intervention de l'utilisateur, la manipulation avec l'objet Date en javascript ne demande aucune intervention de l'utilisateur.
[SNIP]
C'est vrai qu'en France on règle souvent son navigateur sur en_US ou fr_CA.
En France, comme ailleurs, on règle *rarement* son navigateur correctement.
Quel besoin de régler le navigateur, ça se fait tout seul à l'installation en fonction des paramètres du système.
Quoi qu'on fasse il faut faire quelque chose pour récupérer le fuseau
horaire. Ce n'est pas plus complexe d'appeler Date que de faire une liste
déroulante et de récupérer le choix de l'utilisateur du côté du serveur.
Et le faire sur le serveur cela a tout un tas d'avantages.
La, vous demandez une intervention de l'utilisateur, la manipulation
avec l'objet Date en javascript ne demande aucune intervention de
l'utilisateur.
[SNIP]
C'est vrai qu'en France on règle souvent son navigateur sur en_US ou
fr_CA.
En France, comme ailleurs, on règle *rarement* son navigateur
correctement.
Quel besoin de régler le navigateur, ça se fait tout seul à
l'installation en fonction des paramètres du système.
Quoi qu'on fasse il faut faire quelque chose pour récupérer le fuseau horaire. Ce n'est pas plus complexe d'appeler Date que de faire une liste déroulante et de récupérer le choix de l'utilisateur du côté du serveur. Et le faire sur le serveur cela a tout un tas d'avantages.
La, vous demandez une intervention de l'utilisateur, la manipulation avec l'objet Date en javascript ne demande aucune intervention de l'utilisateur.
[SNIP]
C'est vrai qu'en France on règle souvent son navigateur sur en_US ou fr_CA.
En France, comme ailleurs, on règle *rarement* son navigateur correctement.
Quel besoin de régler le navigateur, ça se fait tout seul à l'installation en fonction des paramètres du système.
La, vous demandez une intervention de l'utilisateur,
Non. On laisse la main à l'utilisateur.
la manipulation avec l'objet Date en javascript ne demande aucune intervention de l'utilisateur.
C'est bien son rôle : le confort de l'internaute.
Donc : on laisse toujours le choix à l'utilisateur de *pouvoir* choisir son fuseau horaie, sa langue, etc... et on traite donc ça côté serveur.
Si on a 10 minutes à ne rien foutre et qu'on veut jouer avec JS, on essaye de *deviner* côté client ce que l'utilisateur aurait choisi et on le fait en automatique pour lui, pour son confort. Ca tombe bien, si l'utilisateur n'a pas JS activé, ou si on s'est planté, non seulement l'utilisateur peut quand même accéder à ce qui lui convient, mais en plus on n'a pas une seule ligne de code à changer côté serveur qu'on décide de faire le JS maintenant ou plus tard.
C'est exactement comme pour tous les traitements : ça doit fonctionner sans JS activé (et sans cookies activés), quitte à ce que l'utilisateur doive, du coup, faire deux clics de plus, ou arrive dans une "impasse" de navigation en cas d'erreur de saisie. Mais bon, ça fait des années qu'on le répète et on le répètera encore dans des années. La notion de (rétro)compatibilité ne passera jamais dans les moeurs, alors que c'est primordial pour les utilisateurs.
JG
Bonjour,
La, vous demandez une intervention de l'utilisateur,
Non. On laisse la main à l'utilisateur.
la manipulation
avec l'objet Date en javascript ne demande aucune intervention de
l'utilisateur.
C'est bien son rôle : le confort de l'internaute.
Donc : on laisse toujours le choix à l'utilisateur de *pouvoir* choisir
son fuseau horaie, sa langue, etc... et on traite donc ça côté serveur.
Si on a 10 minutes à ne rien foutre et qu'on veut jouer avec JS, on
essaye de *deviner* côté client ce que l'utilisateur aurait choisi et on
le fait en automatique pour lui, pour son confort. Ca tombe bien, si
l'utilisateur n'a pas JS activé, ou si on s'est planté, non seulement
l'utilisateur peut quand même accéder à ce qui lui convient, mais en
plus on n'a pas une seule ligne de code à changer côté serveur qu'on
décide de faire le JS maintenant ou plus tard.
C'est exactement comme pour tous les traitements : ça doit fonctionner
sans JS activé (et sans cookies activés), quitte à ce que l'utilisateur
doive, du coup, faire deux clics de plus, ou arrive dans une "impasse"
de navigation en cas d'erreur de saisie. Mais bon, ça fait des années
qu'on le répète et on le répètera
encore dans des années. La notion de (rétro)compatibilité ne passera
jamais dans les moeurs, alors que c'est primordial pour les
utilisateurs.
La, vous demandez une intervention de l'utilisateur,
Non. On laisse la main à l'utilisateur.
la manipulation avec l'objet Date en javascript ne demande aucune intervention de l'utilisateur.
C'est bien son rôle : le confort de l'internaute.
Donc : on laisse toujours le choix à l'utilisateur de *pouvoir* choisir son fuseau horaie, sa langue, etc... et on traite donc ça côté serveur.
Si on a 10 minutes à ne rien foutre et qu'on veut jouer avec JS, on essaye de *deviner* côté client ce que l'utilisateur aurait choisi et on le fait en automatique pour lui, pour son confort. Ca tombe bien, si l'utilisateur n'a pas JS activé, ou si on s'est planté, non seulement l'utilisateur peut quand même accéder à ce qui lui convient, mais en plus on n'a pas une seule ligne de code à changer côté serveur qu'on décide de faire le JS maintenant ou plus tard.
C'est exactement comme pour tous les traitements : ça doit fonctionner sans JS activé (et sans cookies activés), quitte à ce que l'utilisateur doive, du coup, faire deux clics de plus, ou arrive dans une "impasse" de navigation en cas d'erreur de saisie. Mais bon, ça fait des années qu'on le répète et on le répètera encore dans des années. La notion de (rétro)compatibilité ne passera jamais dans les moeurs, alors que c'est primordial pour les utilisateurs.
JG
julian
l'idée d'une liste déroulante de timezones est intéressante. trop simple donc je n'y avais pas pensé ;-) merci
l'idée d'une liste déroulante de timezones est intéressante. trop
simple donc je n'y avais pas pensé ;-) merci
