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
Tout à fait, merci de votre aide, il s'agit bien de: putenv("TZ=Europe/Paris");
pour aller plus loin, on m'avait donné ce "truc" pour que php et mysql sortent les mêmes timestamp, alors que ça n'etait pas le cas sur un serveur... va savoir pourquoi
a priori mysql utilisait la bonne timezone, mais pas php, on pouvait alors retablir l'equilibre avec ce putenv('TZ=...');
Tout à fait, merci de votre aide, il s'agit bien de:
putenv("TZ=Europe/Paris");
pour aller plus loin, on m'avait donné ce "truc" pour que php et mysql
sortent les mêmes timestamp, alors que ça n'etait pas le cas sur un
serveur... va savoir pourquoi
a priori mysql utilisait la bonne timezone, mais pas php, on pouvait
alors retablir l'equilibre avec ce putenv('TZ=...');
Tout à fait, merci de votre aide, il s'agit bien de: putenv("TZ=Europe/Paris");
pour aller plus loin, on m'avait donné ce "truc" pour que php et mysql sortent les mêmes timestamp, alors que ça n'etait pas le cas sur un serveur... va savoir pourquoi
a priori mysql utilisait la bonne timezone, mais pas php, on pouvait alors retablir l'equilibre avec ce putenv('TZ=...');
C'est pour cela qu'il faut stocker dans la BDD en GMT
Ok.
et ensuite utiliser Javascript coté client pour faire le calcul pour l'affichage.
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.
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.
-- 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>
C'est pour cela qu'il faut stocker dans la BDD en GMT
Ok.
et ensuite
utiliser Javascript coté client pour faire le calcul pour l'affichage.
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.
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.
--
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>
C'est pour cela qu'il faut stocker dans la BDD en GMT
Ok.
et ensuite utiliser Javascript coté client pour faire le calcul pour l'affichage.
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.
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.
-- 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
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.
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.
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.
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.
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.
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.
CrazyCat
Thibaut Allender wrote:
pour aller plus loin, on m'avait donné ce "truc" pour que php et mysql sortent les mêmes timestamp, alors que ça n'etait pas le cas sur un serveur... va savoir pourquoi
Grosse probabilité: une compilation de PHP avec une mauvaise option locale. Je ne connais pas assez le fonctionnement "interne" de php et de mysql pour pouvoir en dire plus, mais les systèmes sont indépendants et se basent sur l'unixtime du serveur, mais le traite chacun à sa manière.
-- Découvrez Original War: http://www.original-war.org Humour: http://www.chatfou.com Tchattez en liberté: http://www.crazy-irc.net
Thibaut Allender wrote:
pour aller plus loin, on m'avait donné ce "truc" pour que php et mysql
sortent les mêmes timestamp, alors que ça n'etait pas le cas sur un
serveur... va savoir pourquoi
Grosse probabilité: une compilation de PHP avec une mauvaise option locale.
Je ne connais pas assez le fonctionnement "interne" de php et de mysql
pour pouvoir en dire plus, mais les systèmes sont indépendants et se
basent sur l'unixtime du serveur, mais le traite chacun à sa manière.
--
Découvrez Original War: http://www.original-war.org
Humour: http://www.chatfou.com
Tchattez en liberté: http://www.crazy-irc.net
pour aller plus loin, on m'avait donné ce "truc" pour que php et mysql sortent les mêmes timestamp, alors que ça n'etait pas le cas sur un serveur... va savoir pourquoi
Grosse probabilité: une compilation de PHP avec une mauvaise option locale. Je ne connais pas assez le fonctionnement "interne" de php et de mysql pour pouvoir en dire plus, mais les systèmes sont indépendants et se basent sur l'unixtime du serveur, mais le traite chacun à sa manière.
-- Découvrez Original War: http://www.original-war.org Humour: http://www.chatfou.com Tchattez en liberté: http://www.crazy-irc.net
Patrick Mevzek
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 ?
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)
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.
-- 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>
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 ?
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)
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.
--
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>
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 ?
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)
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.
-- 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>
julian
qu'est ce que tu entends par "stocker en GMT" ? tu vas de toutes facons stocker une date qu'il te faudra "traduire" en fonction du client. je recupere la date en bdd, ensuite j'utilise le client pour connaitre son GMT et ajuster la date avant de l'afficher.
il parait que c'est mal d'utiliser le client... ok, mais quelle autre alternative ?
qu'est ce que tu entends par "stocker en GMT" ? tu vas de toutes facons
stocker une date qu'il te faudra "traduire" en fonction du client. je
recupere la date en bdd, ensuite j'utilise le client pour connaitre son
GMT et ajuster la date avant de l'afficher.
il parait que c'est mal d'utiliser le client... ok, mais quelle autre
alternative ?
qu'est ce que tu entends par "stocker en GMT" ? tu vas de toutes facons stocker une date qu'il te faudra "traduire" en fonction du client. je recupere la date en bdd, ensuite j'utilise le client pour connaitre son GMT et ajuster la date avant de l'afficher.
il parait que c'est mal d'utiliser le client... ok, mais quelle autre alternative ?
Sebastian 'CrashandDie' Lauwers
ftc wrote:
Pour que ça puisse être fait côté serveur, il faut connaitre le fuseau horraire du client.
[...]
Non pas nécessairement, il suffit de demander une fois (lors de l'inscriptions?) où se trouve l'utilisateur, dans quel fuseau, on sait donc le calcul à faire.
Amicalement, S.
ftc wrote:
Pour que ça puisse être fait côté serveur, il faut connaitre le fuseau
horraire du client.
[...]
Non pas nécessairement, il suffit de demander une fois (lors de
l'inscriptions?) où se trouve l'utilisateur, dans quel fuseau, on sait
donc le calcul à faire.
Pour que ça puisse être fait côté serveur, il faut connaitre le fuseau horraire du client.
[...]
Non pas nécessairement, il suffit de demander une fois (lors de l'inscriptions?) où se trouve l'utilisateur, dans quel fuseau, on sait donc le calcul à faire.
Amicalement, S.
Guillaume Bouchard
wrote:
et comment ferais tu alors ?
Déjà il faut dégager deux problématiques :
- 1) Le bonheur du client d'avoir l'heure dans sa timezone, je ne sais pas si c'est parfaitement utile. - 2) la necessité pour le fonctionement de l'appli d'avoir l'heure dans la bonne timezone (comme dans le probléme de CrazyCat)
Dans le premier cas, je m'en contrefiche que tu utilises le Javascript, il s'agit d'une fonctions inutile pour le bon fonctionement visant simplement à améliorer le confort de l'utilisateur.
Dans le second, la techno client est incertaine pour cela.
il est hors de question que je dise aux visiteurs "faites la difference vous meme" ;-)
D'un autre coté, si le client se log sur une interface, pourquoi pas dans ces paramétres personels ?
j'ai bien tente de recuperer la timezone via les en-tetes http mais soit ca n'existe pas soit je ne trouve pas.
Aucune idee.
je suis curieux de lire ta reponse a ce propos
Je ne sais pas si elle te convient.
-- Guillaume.
boiteauxlettres@gmail.com wrote:
et comment ferais tu alors ?
Déjà il faut dégager deux problématiques :
- 1) Le bonheur du client d'avoir l'heure dans sa timezone, je ne sais
pas si c'est parfaitement utile.
- 2) la necessité pour le fonctionement de l'appli d'avoir l'heure dans
la bonne timezone (comme dans le probléme de CrazyCat)
Dans le premier cas, je m'en contrefiche que tu utilises le Javascript,
il s'agit d'une fonctions inutile pour le bon fonctionement visant
simplement à améliorer le confort de l'utilisateur.
Dans le second, la techno client est incertaine pour cela.
il est hors de question que je dise aux visiteurs "faites la difference
vous meme" ;-)
D'un autre coté, si le client se log sur une interface, pourquoi pas
dans ces paramétres personels ?
j'ai bien tente de recuperer la timezone via les
en-tetes http mais soit ca n'existe pas soit je ne trouve pas.
- 1) Le bonheur du client d'avoir l'heure dans sa timezone, je ne sais pas si c'est parfaitement utile. - 2) la necessité pour le fonctionement de l'appli d'avoir l'heure dans la bonne timezone (comme dans le probléme de CrazyCat)
Dans le premier cas, je m'en contrefiche que tu utilises le Javascript, il s'agit d'une fonctions inutile pour le bon fonctionement visant simplement à améliorer le confort de l'utilisateur.
Dans le second, la techno client est incertaine pour cela.
il est hors de question que je dise aux visiteurs "faites la difference vous meme" ;-)
D'un autre coté, si le client se log sur une interface, pourquoi pas dans ces paramétres personels ?
j'ai bien tente de recuperer la timezone via les en-tetes http mais soit ca n'existe pas soit je ne trouve pas.
Aucune idee.
je suis curieux de lire ta reponse a ce propos
Je ne sais pas si elle te convient.
-- Guillaume.
Patrick Mevzek
qu'est ce que tu entends par "stocker en GMT" ?
Quand vous stockez une date dans une base de données, si vous faites les choses proprement, vous stockez la date *avec* l'information sur le fuseau horaire. Vous pouvez donc stocker une date dans n'importe quel fuseau, tant que vous spécifiez le fuseau.
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.
Cela permet ainsi aisément de comparer les choses, et d'avoir un référentiel commun, même si pour faciliter la vie à l'utilisateur vous lui indiquez la date dans son fuseau horaire spécifique.
-- 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>
qu'est ce que tu entends par "stocker en GMT" ?
Quand vous stockez une date dans une base de données, si vous faites les
choses proprement, vous stockez la date *avec* l'information sur le
fuseau horaire.
Vous pouvez donc stocker une date dans n'importe quel fuseau, tant que
vous spécifiez le fuseau.
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.
Cela permet ainsi aisément de comparer les choses, et d'avoir un
référentiel commun, même si pour faciliter la vie à l'utilisateur vous
lui indiquez la date dans son fuseau horaire spécifique.
--
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>
Quand vous stockez une date dans une base de données, si vous faites les choses proprement, vous stockez la date *avec* l'information sur le fuseau horaire. Vous pouvez donc stocker une date dans n'importe quel fuseau, tant que vous spécifiez le fuseau.
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.
Cela permet ainsi aisément de comparer les choses, et d'avoir un référentiel commun, même si pour faciliter la vie à l'utilisateur vous lui indiquez la date dans son fuseau horaire spécifique.
-- 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>
julian
Stockage en GMT...OK. Pas bête, même si je ne pense pas que mes données seront hébergées autre part qu'en France.
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.
Stockage en GMT...OK. Pas bête, même si je ne pense pas que mes
données seront hébergées autre part qu'en France.
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.
