Alors, le test suivant est plutôt concluant:
echo fdate(mktime(0, 0, 0, 5, 10, 2009));
mais par contre dans ma boucle qui recupère des timestamps de mysql,
ça va pas:
else{$retour = mysql_query("SELECT titre,accroche,article,date FROM
article1 ORDER BY date DESC LIMIT 0,4")or die(mysql_error());}
Version finale MySQL: 5.0.51 (free) et là : Version du client MySQL: 5.0.51a
la "méthode" d'Antoine, cest pas moins bien au niveau de la "grosseur" des requêtes que jenvoie à ma base?
merci
Sylvain SF
samuel a écrit :
cest la requête qui n'aboutit pas
Version finale MySQL: 5.0.51 (free)
ça devrait aboutir. donne le msg d'erreur au cas où.
la "méthode" d'Antoine, cest pas moins bien au niveau de la "grosseur" des requêtes que jenvoie à ma base?
SELECT DATE_FORMAT(date,'%W %e %M %Y %kh %imn %ss') FROM article1 comparé à SELECT date FROM article1
oui, ça prendra qlq octets de plus pour le requête transmisse mais cela n'a pas d'impact - il est courant d'avoir des requêtes de plusieurs centaines de caractères.
le temps de traitement global sera plus court avec DATE_FORMAT qu'avec la routine PHP; le choix de la méthode peut dépendre de la charge du serveur MySQL et du serveur Apache/PHP, si c'est ma même machine, on peut se simplifier la vie et faire la mise en forme via MySQL.
un problème peut néanmoins apparaître dans ce cas, la localisation n'est pas garantie, 'lc_time_names' est introduit avec la release 5.1.12 (donc pas dispo en 5.0.51) et son affectation nécessite le privilège 'SUPER' ce qui est rarement le cas.
tu pourrais malgré tout dans ce cas faire un replace Monday, Lundi en PHP.
Sylvain.
samuel a écrit :
cest la requête qui n'aboutit pas
Version finale MySQL: 5.0.51 (free)
ça devrait aboutir. donne le msg d'erreur au cas où.
la "méthode" d'Antoine, cest pas moins bien au niveau de la "grosseur"
des requêtes que jenvoie à ma base?
SELECT DATE_FORMAT(date,'%W %e %M %Y %kh %imn %ss') FROM article1
comparé à
SELECT date FROM article1
oui, ça prendra qlq octets de plus pour le requête transmisse
mais cela n'a pas d'impact - il est courant d'avoir des requêtes
de plusieurs centaines de caractères.
le temps de traitement global sera plus court avec DATE_FORMAT
qu'avec la routine PHP; le choix de la méthode peut dépendre
de la charge du serveur MySQL et du serveur Apache/PHP, si c'est
ma même machine, on peut se simplifier la vie et faire la mise
en forme via MySQL.
un problème peut néanmoins apparaître dans ce cas, la localisation
n'est pas garantie, 'lc_time_names' est introduit avec la release
5.1.12 (donc pas dispo en 5.0.51) et son affectation nécessite le
privilège 'SUPER' ce qui est rarement le cas.
tu pourrais malgré tout dans ce cas faire un replace Monday, Lundi
en PHP.
ça devrait aboutir. donne le msg d'erreur au cas où.
la "méthode" d'Antoine, cest pas moins bien au niveau de la "grosseur" des requêtes que jenvoie à ma base?
SELECT DATE_FORMAT(date,'%W %e %M %Y %kh %imn %ss') FROM article1 comparé à SELECT date FROM article1
oui, ça prendra qlq octets de plus pour le requête transmisse mais cela n'a pas d'impact - il est courant d'avoir des requêtes de plusieurs centaines de caractères.
le temps de traitement global sera plus court avec DATE_FORMAT qu'avec la routine PHP; le choix de la méthode peut dépendre de la charge du serveur MySQL et du serveur Apache/PHP, si c'est ma même machine, on peut se simplifier la vie et faire la mise en forme via MySQL.
un problème peut néanmoins apparaître dans ce cas, la localisation n'est pas garantie, 'lc_time_names' est introduit avec la release 5.1.12 (donc pas dispo en 5.0.51) et son affectation nécessite le privilège 'SUPER' ce qui est rarement le cas.
tu pourrais malgré tout dans ce cas faire un replace Monday, Lundi en PHP.
