Discussion :

[redah75]

Bonjour, et j'espere que je poste au bon endroit.

je galere depuis hier pour fixer une maniere a gerer les dates ainsi que le decalage horaire. je crée actuellement un site marchand bilingue: francais et anglais (US & UK). j'ai opté pour des fichier xml pour la traduction du site et je suis en version 5.2.14 de PHP

1- lorsqu'un client achete un produit, quelle date d'achat enregistrer dans la base de donné?
j'ai pense a mettre la date francaise et dans un autre champ, j'inserer +/-X, où X est le nombre d'heure de decalage. est ce bon ou y a t-il mieux? et comment pourrais je recuperer le nombre d'heures de decalage??

2- lorsque j'extrais une date d'une bdd, quelle est la meilleure maniere de l'afficher selon la langue du site?
j'ai entendu parlé de sprintf, vprintf, ... mais je ne vois pas trop son utilité puisque je peux afficher ma date de cette maniere:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

$date_uk = $day." of ".$month.", ".$year;

je vous prie de bien vouloir m'eclairer un peu a ce sujet. je suis dans le flou total!!

Merci

[Thes32]

salut,

le mieux est peut être d'enregistrer le timestamp (qui est toujours indépendant du timezone), et en fonction du timezone affichée la date.

Pour cel tu devras utiliser les classes DateTime et DateTimeZone qui existent dans PHP depuis la version 5.1.

[redah75]

merci pour la reponse et aussi pour le lien. je le lis tout de suite!!

le mieux est peut être d'enregistrer le timestamp (qui est toujours indépendant du timezone), et en fonction du timezone affichée la date.

je ne vois pas trop ce que tu veux dire par "independant du timezone"
la date en timestamp n'est il pas egal a strtotime("2010-11-16 11:13:35") ??

[redah75]

et une petite precision: la fonction date_default_timezone_get() s'execute coté serveur?? il y a donc aucun moyen en php de savoir que monsieur X qui est à New York que son fuseau est 'America/New_York' ??

[RunCodePhp]

Salut

Comme tu parle d'achat de produits, donc de commerce en ligne, et bien quel intérêt il y a il de mettre la date de commande (facture) en fonction de la situation géographique du client ?

L'achat s'est effectué sur ton site, c'est cette heure là qui fait plutôt référence, non ?

En tout cas, quand je commande quelque chose en France Métropolitaine, la date de commande c'est celle de la France, pas celle de la Réunion où j'ai commandé.

De même que tu évoque de mettre la date selon la langue.
Là c'est pareil. Si c'est un Japonnais par exemple, vas tu mettre la date du Japon et dans cette langue aussi ?
Ca risque d'être un peu compliqué je pense.

il y a donc aucun moyen en php de savoir que monsieur X qui est à New York que son fuseau est 'America/New_York' ??

Personnellement, j'en ai pas connaissance.
Tout ça s'apparente à la géolocalisation, je sais d'ailleurs que tu as déjà recourt à un de ces services.

Faudrait voir par exemple ce que tu as dans ta Base de Données s'il y a moyen de rajouter par là un champs genre "timezone" pour les renseigner, ne serait ce qu'aux Pays par exemple.

[redah75]

Bonjour RunCodePhp, cava??

Comme tu parle d'achat de produits, donc de commerce en ligne, et bien quel intérêt il y a il de mettre la date de commande (facture) en fonction de la situation géographique du client ?
L'achat s'est effectué sur ton site, c'est cette heure là qui fait plutôt référence, non ?

c'est la grande question que je me pose! si un americain achete sur mon site a 3h du mat heure francaise (18h heure à Los Angeles), ne serait il pas bizarre qu'il voit sur son historique de commande, une heure qui ne correspond pas du tout a l'heure de son achat?

De même que tu évoque de mettre la date selon la langue.
Là c'est pareil. Si c'est un Japonnais par exemple, vas tu mettre la date du Japon et dans cette langue aussi ?

non pas en japonais le site sera en francais et anglais (UK & international)
sur le site francais j'afficherai la date: 15 decembre 2010, en UK: december 15th 2010. pareil pour les prix, il y a un format pour la france, un autre pour le royaume uni et pour les USA (15.50 €, $15,00, ...)

Faudrait voir par exemple ce que tu as dans ta Base de Données s'il y a moyen de rajouter par là un champs genre "timezone" pour les renseigner, ne serait ce qu'aux Pays par exemple.

j'ai pensé a rajouter un champ "time zone" par pays mais ca ne marchera pas bien puisque la russie et les usa par exemple ont plusieurs fuseaux horaires. la seule solution c'est que je demande a l'utilisateur de selectionner son fuseau horaire. mais apres tout, est ce vraiment interessant de faire tout cela????!!

e sais d'ailleurs que tu as déjà recourt à un de ces services.

j'ai d'ailleurs pensé a toi car j'ai carrement posé la question a WIPmania par rapport a l'utilisation de leurs api et voici leurs reponse que j'ai eue avant hier:

Dear Reda,
that's right, api is also free for comercial purposes
the main api is to find on the
http://www.wipmania.com/en/api/
...

[RunCodePhp]

Bonjour RunCodePhp, cava??

Des petits soucis comme tout l'monde, sinon ça va

c'est la grande question que je me pose! si un americain achete sur mon site a 3h du mat heure francaise (18h heure à Los Angeles), ne serait il pas bizarre qu'il voit sur son historique de commande, une heure qui ne correspond pas du tout a l'heure de son achat?

Ca correspond à son heure d'achat, sauf que c'est à lui de faire la petite gymnastique.
En quoi cela serait bizarre ?
Tu n'a jamais commandé sur le Net ?

Franchement, je n'est jamais vu une date de commande avec le fuseau horaire de la Réunion, là où je réside.
L'inverse me surprendrait d'ailleurs, je m'attends plutôt que ça soit l'heure où se situe la boutique, c'est d'ailleurs de là où le colis partirait.

Aussi, quand le client va payer, il va surement être redirigé vers une application externe d'une banque (ou genre PayPal, peu importe), et là aussi l'heure de la transaction ne sera pas celle de la Réunion, mais là où se situe la banque.
Ou est le problème ?



J'ai plutôt l'impression que ce ne serait pas une question de situation géographique, mais de la langue de l'interface, celle qu'aura choisi le client (utilisateur), ou celle proposée par défaut.
Donc quelque part, le "timezone" serait lié à la langue, et non au Pays.


Aussi, la plupart des sites Web e-commerce (du moins ceux que j'ai vu) évitent les traductions à ce niveau, ils indiquent plutôt des dates du genre 17/11/2010 15:43 ou alors 2010-11-17 15:43.
Soit 2 formats de date basiques "passe partout", c'est bien plus simple, et surtout moins "casse gueule".


Puis c'est un poil plus compliqué que ça, car concernant les traductions automatique au niveau des date en Php, théoriquement c'est lié au setlocale() (la fonction), mais pas au date_timezone_set() (un timezone).
Le setlocal() étant lié au sytème (l'OS), il faut que le système intègre les langues qu'on souhaite manipuler, sinon c'est foutu.
Enfin, foutu, dans le sens où il faudra le faire "à la mano".


D'ailleurs, et en espérant ne pas dire une bêtise, mais concernant la classe DateTime, toutes les dates sont en Anglais, aucun moyen (aucune config coté Php) d'obtenir une date en Français par exemple, même avec un timezone du genre "Europe/Paris".
Si on veut le faire avec cette classe DateTime, il faut créer une classe dérivée ensuite "à la mano", comme passer par des tableaux de remplacement de chaine par exemple.


En finalité, le setlocale() + les fonctions de bases de Php reste le seul moyen d'avoir des date traduites automatiquement (sans sur-couche perso).
Sauf erreur bien sûr.

j'ai d'ailleurs pensé a toi car j'ai carrement posé la question a WIPmania par rapport a l'utilisation de leurs api et voici leurs reponse que j'ai eue avant hier:

Ah ben, sympa ça.

Donc même le service est libre, tout le monde peu l'utiliser.
D'ailleurs, je remarque qu'ils ont barrés la mention qui mettait une certaine limite de requête HTTP par jour.
Il y aurait même plus de limite maintenant ... que demande le peuple

Using API is free for any purpose, personal or business, (Mention barrée : if you are making fewer than 10.000 requests) and it is unlimited per day

[redah75]

Des petits soucis comme tout l'monde, sinon ça va

les soucis font partie de la vie, sans soucis, la vie ne sera JAMAIS autant appréciée

Tu n'a jamais commandé sur le Net ?

si si, beaucoup meme, mais jamais sur des sites etrangers. amazon est international mais j'ai acheté sur amazon.fr
et franchement, tu me donnes LA solution. j'utiliserai donc un fuseau horaire par langue de site et non pas par pays d'utilisateur.
j'ai 3 langues: fr-fr, en-us et en-gb, j'ai donc un fichier config.php dans chaque langue et j'y mettrai maintenant un date_default_timezone_set().
Pour la france ca sera Europe/Paris, UK -> Europe/London, mais quoi mettre pour les USA ? ils ont 3 ou 4 fuseaux differents??

D'ailleurs, je remarque qu'ils ont barrés la mention qui mettait une certaine limite de requête HTTP par jour.

Oui, avant c'etait limité a 10000 requetes par jour je pense et maintenant c'est illimité. c'est cool

je reviens maintenant sur ma question au sujet de la fonction printf()
quel est l'interet d'utiliser:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

printf ('%1$d of %2$s, %3$d', $day, $month, $year)

au lieu de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

echo $day." of ".$month.", ".$year;

??

MErci infiniment de votre aide

[RunCodePhp]

et franchement, tu me donnes LA solution. j'utiliserai donc un fuseau horaire par langue de site et non pas par pays d'utilisateur.

Je ne pense pas, j'ai plutôt fait fausse route, répondu trop vite, peut être à cause de la langue justement.

Si on prend la réalité, comment sont fait les fuseaux horaires, ils n'ont déjà aucun rapport avec les langues, mais des pays.
- La Belgique à 2 langues (Français et Flamand), ce n'est pas pour autant que les fuseaux diffèrent.
- La France se trouve dans une petite partie à cheval sur 2 fuseaux horaires, ce n'est pas pour autant qu'il y en a 2, mais 1 seul pour des raisons pratiques, pour l'ensemble du pays.
Se rajoute encore des raisons économiques (toujours lié au pays) qui débouche sur des heures été/hivers.

Ton idée au départ qui est de lier ça au Pays reste à mon sens plus logique.
La langue, la traduction de l'heure serait finalement un autre problème.

Enfin, je te donne ma façon de voir. (je révise mon jugement en somme).

Reste maintenant sur quoi, ou comment faire avec ces fuseaux horaires.
Pas lier aux pays puisque certains pays ont plusieurs fuseaux horaires.
Le problème c'est que je ne suis pas spécialiste des fuseaux horaires, sur quoi ils été défini.

Est ce sur des villes ?
Est ce sur des états, département, région, canton, ... ???
Personnellement j'en sais rien.

Si on ne sait pas trop et si on ne veut pas prendre de risque, en liant les timezone aux villes ça va le faire je pense.
Le gros problème c'est que stocker les villes du monde entier, ça va être chaud.


Franchement, faudrait que tu réfléchisse si le jeu en vaut la chandelle, car ça me parait énorme pour un gain qui serait vraiment minime.
Je doute d'ailleurs que la législation imposerait de mettre une date selon le fuseau horaire où se trouve le client.

En plus, faut voir comment tu compte enregistrer cette info coté Bdd, de l'heure j'entends.
Si par exemple tu enregistre l'heure des commandes comprenant le décalage horaire des utilisateur, ça veut dire que toutes les heures dans la Bdd n'auront pas du tout la même base/référence.
Si un jour tu souhaite sortir une stat du genre :
Toutes les commandes entre 10h00 et 11h00 heures de la boutique (ou serveur)
ça va être rudement compliqué à mon avis.
Ici, il vaudrait mieux utiliser une base commune comme l'heure UTC par exemple, et faire les conversions après coup, là où c'est nécessaire et selon le timezone.


A la limite, commence par savoir comment tu vas faire pour obtenir le fuseau horaire de l'utilisateur, car c'est comme pour la géolocalisation sur IP (genre WIPmania).
La manière de l'obtenir pourrait changer la donne, qui sait.
Est ce que WIPmania renseigne le fuseau horaire d'ailleurs ?
Si ce n'est pas le cas, faudrait voir si un tel service existe.
Personnellement j'en sais rien, j'ai jamais recherché ça.
Par contre, il est possible d'obtenir le nombre de d'heure de décalage horaire en Javascript avec la fonction getTimezoneOffset().

je reviens maintenant sur ma question au sujet de la fonction printf()

Dans l'exemple de code que tu donne suppose qu'il y aurait un mariage entre cette fonction sprintf et aussi l'utilisation de gettext() à mon avis.
C'est un peu compliqué à expliquer, car gettext() c'est déjà une manière particulière de gérer des contenus linguistiques, mais très intéressantes.
Voir la doc Php : gettext()

Si tu ne connais pas gettext() ou si ce n'est pas l'orientation que tu envisage, alors regarde les exemples de la fonction sprintf(), on peu faire des choses intéressantes sur les langues rien qu'avec celle ci.

[redah75]

...
Si un jour tu souhaite sortir une stat du genre :
Toutes les commandes entre 10h00 et 11h00 heures de la boutique (ou serveur)
...

oh llaaaa, c'est vrai que j'ai pas trop pensé a ce detail, mais en aurais je vraiment besoin???
ce qui peut arriver, c'est de vouloir afficher les commandes d'un jour J, et que certaines commandes soient passées apres minuit en france et avant minuit dans d'autres pays... mais d'autres part elle passera pour le jour suivant ou precedant et cette commande ne sera pas perdu!
c'est un choix a faire, et je m'arrache vraiment les cheveux, je ne sais plus quoi faire!!

je pense que ca devient vitre ingerable de vouloir gerer les fuseaux horaires par ville. je ne cherche pas a faire un site parfait a 100%, j'aimerais juste offrir un certain confort a l'utilisateur...

une autre solution sera de mettre le fuseau horaire par default sur tout le site a GMT 00 puis lorsque j'affiche la date sur le site americain, ca sera November 12, 2010 GMT +06.00

encore une autre solution sera de demander a l'utilisateur de choisir son fuseau horaire lors de son inscription sur le site, et la ca fera une saisi suplementaire a l'internaute si c'est un champ obligatoire...

Est ce que WIPmania renseigne le fuseau horaire d'ailleurs ?

hehe, wow! tu lis dans mes pensees, j'ai envoyé un mail il y a moins d'une heure a WIPmania pour leur demander si on peut recuperer le fuseau horaire depuis leur api. je te tiens informé de la reponse

pour formater les prix, j'ai choisi cette methode. est la bonne et plus optimisée??

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
setlocale(LC_ALL, 'fr_FR');
define("MONEY_FORMAT", '%!n €');
 
$number = 17234.56787;
echo money_format(MONEY_FORMAT, $number);

...
C'est un peu compliqué à expliquer, car gettext() c'est déjà une manière particulière de gérer des contenus linguistiques, mais très intéressantes.
...

j'ai opté pour des fichiers .xml pour la traduction des sites web...
je vois bien le fonctionnement de sprintf, mais je ne vois juste pas trop l'interet de l'utiliser puisque echo $day." of ".$month.", ".$year; peut faire l'affaire. il y a surement un detail qui m'échappe...

[RunCodePhp]

une autre solution sera de mettre le fuseau horaire par default sur tout le site a GMT 00 puis lorsque j'affiche la date sur le site americain, ca sera November 12, 2010 GMT +06.00

La manière dont tu présente cette date n'est pas du tout standard.

Il faut mettre l'heure, et si tu mets l'heure GMT, ça sera obligatoirement +00.00
Il faut donc que l'heure comporte un décalage horaire pour qu'il y est un certain nombre au niveau du GMT.
Donc soit c'est l'heure du client Américain : November 12, 2010 08:00 GMT -06.00 (soit 14h00 heure GMT)
Ou soit c'est l'heure de ta boutique : 12 Novembre 2010 15h00 GMT +01.00 (soit 14h00 heure toujours)

Si tu n'indique pas l'heure, c'est +6 heures, mais par rapport à quoi ?

je pense que ca devient vitre ingerable de vouloir gerer les fuseaux horaires par ville. je ne cherche pas a faire un site parfait a 100%, j'aimerais juste offrir un certain confort a l'utilisateur...

C'est pas de gérer par ville ou autre, c'est de vouloir gérer les décalage horaires tout court qui est ingérable.
Puis le confort que tu estime, j'en suis absolument pas convaincu.
Si on est logique, un client qui passe commande sur ta boutique revient en quelque sorte qu'il se déplace sur ta boutique, du coup, il parait quasi évident que l'heure de la commande est celle de la boutique, pas celui de l'utilisateur.

Je te conseils d'aller consulter des forums ou autre pour rechercher des infos sur ce point, car j'ai vraiment le sentiment que tu te mets une contrainte (ou confort) qui n'existerait même pas.


A la limite, crée toi un banal champ supplémentaire dans la table commande (genre decalage_horaire), et tu mets le décalage horaire, comme +06.00 ou +0600 qui sont normalement les 2 standards.
Sans rien de plus.
Rien que ceci te permettras d'obtenir ce que tu veux, et surtout te laisser le temps d'y voir plus clair.


Encore une fois, Javascript te permet de récupérer le décalage horaire qu'il y a sur le poste client, donc pas besoin de service externe pour ça.

encore une autre solution sera de demander a l'utilisateur de choisir son fuseau horaire lors de son inscription sur le site, et la ca fera une saisi suplementaire a l'internaute si c'est un champ obligatoire...

N'oublie pas qu'un site Web se veut de pouvoir commander n'importe où et n'importe quand.
Donc une personne qui au départ crée un compte client de chez lui, donc un fuseau horaire, aura la possibilité de commander ailleurs (lieu de vacance par exemple), autre pays, du coup autre fuseau horaire, mais voudra se faire livrer toujours à la même adresse.
Dans ce cas là il y aura une incohérence entre le décalage horaire réel du navigateur et de l'adresse.
De même que si le client commande de chez lui, mais souhaite faire livrer sur une autre adresse, autre fuseau horaire, là encore il y aura une incohérence.

Donc lier un décalage horaire à une adresse ou compte client n'est forcément une bonne idée.
Le décalage horaire serait (entre autre) lié à la commande à mon avis.

Le récupérer lorsque le client cliquera sur "commander" me semble le plus simple et plus sûr, non ?

pour formater les prix, j'ai choisi cette methode. est la bonne et plus optimisée??

Franchement j'en sais rien
Je dirais qu'il faudrait faire gaffe à ton service de paiement en ligne, les caractères, langue, charset, encodage, etc ... peu avoir une certaine importance.
Si cela ne perturbe rien à ce niveau, alors pourquoi pas.

[redah75]

apres une longue periode de reflexion, je pense que je vais ou bien negliger ce detail de decalage horaire. ou sinon au pire des cas, je crée un champ comme tu as dit qui contient ou bien le decalage horaire (-6, +2, ...) ou carement la date du client. qu'est ce que tu choisirais toi??

je reviens sur une question que j'ai posé en premier:
quelle est la reelle difference entre

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

printf ('%1$d of %2$s, %3$d', $day, $month, $year)

et

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

echo $day." of ".$month.", ".$year;

?
qu'est ce qui m'echappe??

[RunCodePhp]

qu'est ce que tu choisirais toi??

Si ça tenais qu'à moi, je ne ferais rien du tout.
Mais au pire, comme j'ai dis précédemment, l'heure du serveur (boutique) et éventuellement un champ avec le décalage horaire genre +06:00 (d'un format standard).
Il ne faut pas juste prévoir les heures, car il y a des endroits dans le monde où il y a des minutes aussi (des 1/2 heures, des 1/4 heures).

quelle est la reelle difference entre

Finallement, il n'y aurait pas de gettext() qui se cacherait dérrière.
Regarde la fonction sprintf, les exemples que donne la doc : http://fr2.php.net/manual/fr/function.sprintf.php
Entre autre ceci :
La phrase à la base est : "Il y a 5 singes dans le bananier".
Ca concerne 5 (pour %1$d) et bananier (pour %2$s)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
$format = 'Le %2$s a %1$d singes';
printf($format, $num, $location);

Et ceci aussi :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
$format = 'Le %2$s a %1$d singes.
           C\'est un beau %2$s avec %1$d singes.';
printf($format, $num, $location);

A titre d'exemple (et simple)
Pour que ceci soit intéressant, il faut que l'on stock quelque part un format de date, mettons, un format de date pour une commande.
Peu importe la manière dont sera stocké le format (xml, php, Bdd, etc ...).

Admettons qu'on a 2 langues, Français et Anglais, il faudra alors 2 formats.

Et bien on fera en sorte de stocker 2 formats du genre :
Français : %1$d %2$s %3$d
Anglais : %2$s of %1$d, %3$d
Le but recherché :
Français : 18 Novembre 2010
Anglais : November 18, 2010

Donc si un visiteur navigue en Anglais, on va va faire en sorte d'avoir une variable $format_date_commande qui aura comme valeur ici : %2$s of %1$d, %3$d
Si c'est un visiteur qui navigue en Français, la valeur sera cette fois : %2$s of %1$d, %3$d.
Cette variable sera initialisée avec le contenu qu'on aura récupéré (xml, php, Bdd, peu importe).

Du coup, dans la page HTML qui génère la commande, la ligne de la date sera :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

printf ($format_date_commande, $day, $month, $year)

Ce code là ne change jamais, on peu considérer ça comme une matrice.
C'est le fait d'obtenir qu'un seul code unique au bout qui fait que ça change pas mal, il n'y a pas l'ombre d'une alternative, tout est dynamique.
Ton code réclamera normalement autant d'alternatives qu'il y a de langues/formats.


Petite bémol dans cet exemple, car dans les 2 cas (Français ou Anglais) le mois November n'est pas traduit pour autant.
On peu encore étendre le truc comme par exemple importer une liste de traductions mois, sous forme de tableau avec le même principe.

Au bout :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
printf ($format_date_commande, $day, $liste_mois[$month], $year);

$month serait plutôt un nombre : 0 pour Dimanche (ou Sunday), 1 pour Lundi (ou Monday), etc ... selon la langue.


Je ne sais pas si mes explications sont bonnes, si tu vois le truc, je l'ai fait texto comme c'est venu.

[stealth35]

vive Intl
http://fr2.php.net/manual/fr/intldat...ter.format.php

[redah75]

Si ça tenais qu'à moi, je ne ferais rien du tout.

eh ben je laisse alors tel quel, je ne vais pas perdre mon temps et me prendre la tete la dessus!!

au fait, j'avais deja vu toutes les explications concernant le sprintf mais je ne vois pas trop son utilité puisque j'ai pu formater mes dates en utilisant la methode suivante:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
define("FORMAT_DATE_DAY", "{day_num_week}, {month_num} {day_num_month}, {year}");
define("FORMAT_DATE", "{month_num} {day_num_month}, {year}");
 
function show_date($format, $dt) {
	global $sxml;
 
	list($year, $month_num, $day_num_week, $day_num_month, $day_suffix) = explode("-", date("Y-n-N-j-S", strtotime($dt)));
	$month_num = $sxml->{'month'.$month_num}; // pour afficher le mois dans la langue du site web
	$day_num_week = $sxml->{'day'.$day_num_week};
 
	$search = array("{year}", "{month_num}", "{day_num_week}", "{day_num_month}", "{day_suffix}");
	$replace = array($year, $month_num, $day_num_week, $day_num_month, $day_suffix);
 
	return str_replace($search, $replace, $format);
}
 
// sur le site US cela affiche Thursday, November 18, 2010
echo show_date(FORMAT_DATE_DAY, "2010-11-18 12:59:52");

la question alors est: qu'est ce que sprintf peut m'apporter de plus??

j'ai par contre un petit soucis avec ce que j'ai fait, dans la mesure ou il va toujours me remplacer les numeros de mois par le mois (nov, oct, ...)
comment pourrais je faire pour afficher une date du type 11/18/2010 ??

[RunCodePhp]

la question alors est: qu'est ce que sprintf peut m'apporter de plus??

Je t'ai donné un exemple précédemment.

Mais le sprinf() ne s'impose pas, c'est juste une solution parmi tant d'autres, y compris IntlDateFormatter.
Tu as choisi une voie différente, vouloir l'exploiter ne va peut être rien améliorer du tout.

comment pourrais je faire pour afficher une date du type 11/18/2010 ??

Je ne vois pas trop.
Ne faudrait pas pas un autre format (autre constante) prévu pour ?

vive Intl

C'est rageant, car des librairies PECL, on dirait qu'il y en a de plus en plus, c'est Objet et le peu que j'ai vu c'est vachement bien goupillé.
Le gros blême c'est quand on est sur un petit mutualisé, on a droit à rien du tout

[stealth35]

C'est rageant, car des librairies PECL, on dirait qu'il y en a de plus en plus, c'est Objet et le peu que j'ai vu c'est vachement bien goupillé.
Le gros blême c'est quand on est sur un petit mutualisé, on a droit à rien du tout

ouai faut être patient, Intl sera bientôt la d'office, elle est intégré depuis un moment dans la distrib windows, et elle sera de la partie dans le prochain debian, c'est plus une extension du type bundle, en la mettant en shared, ca marchait pas top

ps : et bientôt elle aura le Transliterator

[redah75]

Je ne vois pas trop.
Ne faudrait pas pas un autre format (autre constante) prévu pour ?

si, je mettrai une autre variable constante mais le numero du mois sera automatiquement remplacé par le nom du mois. la solution que j'ai est de creer une autre variable avec le explode("-", date("Y-n-N-j-S", strtotime($dt))); qui ne sera jamais traduite, mais je me demandais s'il y a avait mieux...

je viens tout juste de me rendre compte que la methode que j'ai trouvé pour formater les prix ne marchera pas trop bien dans mon cas.
je voulais par exemple mettre

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
setlocale(LC_MONETARY, 'fr_FR');
define("MONEY_FORMAT", '%!n €');
 
$number = 17234.56787;
echo money_format(MONEY_FORMAT, $number);

pour le site francais, mais sachant que je donne au client la possibilité de changer la devise, le code ci-dessus ne sera plus valable. quelle methode aurais tu choisie??

[redah75]

bonsoir,
j'ai fait quelques ameliorations dans ma fonction qui formate les date que voici si ca peut interesser quelqu'un.
RunCodePhp: tu as bien eu raison d'insister un peu sur la fonction sprintf. je viens de me rendre compte qu'elle presente bien plus d'avantages que la solution presentee précédemment!!

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
// fichier de config anglais:
define("FORMAT_DATE_DAY", '%1$s, %4$s %2$d, %5$d'); // Friday, November 19, 2010
define("FORMAT_DATE", '%4$s %2$d, %5$d'); // November 19, 2010
define("FORMAT_DATE_SHORT", '%3$d/%2$d/%5$d'); // 11/5/2010 without 0
 
//fichier de config francais:
define("FORMAT_DATE_DAY", '%1$s %2$d %4$s %5$d'); // Mardi 19 Novembre 2010
define("FORMAT_DATE", '%2$d %4$s %5$d'); // 19 Novembre 2010
define("FORMAT_DATE_SHORT", '%2$02d/%3$02d/%5$d'); // 05/11/2010 avec 0
 
function show_date($format, $dt) {
	global $sxml;
 
	list($day_week, $day, $month, $year) = explode("-", date("N-j-n-Y", strtotime($dt)));
	$month_char = $sxml->{'month'.$month};
	$day_char = $sxml->{'day'.$day_week};
 
	return sprintf ($format, $day_char, $day, $month, $month_char, $year);
}
 
echo show_date(FORMAT_DATE, "2010-11-08 09:59:52");

qu'en pensez vous??

[RunCodePhp]

qu'en pensez vous??

Et bien tu vois qu'en insistant un peu on parvient à trouver le truc.

Petite remarque au passage.
Tu prévois de déclarer $sxml en global dans la fonction. Mais celle ci est tout aussi obligatoire que les 2 paramètre $format et $dt.
Pourquoi donc ne pas le mettre aussi en paramètre ?
D'une part, $sxml n'est pas modifié, juste exploité, puis quand bien même, apparemment $sxml serait un Objet, et depuis Php5, tout Objet "passe" par référence, donc ça ne change rien.
D'ailleurs, ça peu se faire ainsi :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

show_date(MonObjet $sxml, $format, $dt) { ... etc ...}

Si $sxml n'est pas un Objet MonObjet, ça génèrera une erreur (ça renforce son code).

D'ailleurs, pour formater des prix Français/Anglais, tu pourrais adopter le même principe, car la position des symboles (€/$) cause à peu près le même problème.
La solution est simple, et efficace.
Attention tout de même au symbole Euro €, donc en entité HTML. C'est justement uniquement pour du HTML (donc spécifique), et si tu compte générer autre chose comme du XML, PDF, RTF, etc, etc ... ça peu être un inconvénient.


Après ça, chacun sa manière de faire.
Peut être est il trop tôt d'en parler, mais faire ce genre de chose de manière Objet (POO) se prête théoriquement bien mieux que des successions de fonctions.
D'ailleurs, tu risque à force d'en avoir beaucoup.
La POO permet de construire comme ça des Objets qui auront pour mission de gérer chaque cas.
(date, prix, poids, client, produit, panier, commande, etc, etc ...)