Forum d'entraide PHPFrance

Bonjour

Mon problème, après deux jours de recherche pas trouvé une solution qui replace ma date en français dans le post retour

explications

je sauve ma requête dans la base de données :

$sql = "INSERT INTO `tiny` (`date_post`, `text`) VALUES (NOW(), '$text')";

je récupère dans mon formulaire :

echo 'Ce Message a &#233;t&#233; post&#233; le :  '.$data['date_post'].'    '.$data['text'].'<br />';

résultat voir image : la date commence par l'année !


merci par avance !

si la date n'est utilisée qu'en cette occasion, une solution est d'utiliser http://dev.mysql.com/doc/refman/5.5/en/ ... ate-format dans la requete sql; par exemple
select DATE_FORMAT(date_post, '%e-%m-%Y') as date_post from ...

ou placer cette requête ?

select DATE_FORMAT(date_post, '%d-%m-%Y') as date_post from ...


est à mettre dans la base SQL ou dans une page PHP ??

Pour les dates, oui elles sont rangées du plus grand au plus petit dans les tables d'un SGBD (année puis mois puis jours,...).

Tu as aussi une solution très simple et qui marche très bien:
lorsque tu récupères ta variable avec la valeur 2015-02-05, tu splites avec un explode (ton split est le tiret du six)
pour obtenir trois variables: une pour l'année, une pour le mois et une pour le jour.
Ensuite, pour retrouver ta variable initiale dans l'ordre inverse, tu peux:
- soit faire une simple contaténation en php: variable jour + tiret du six + variable mois + tiret du six + variable année
- soit faire un implode en mettant tes variables dans le nouvel ordre, sachant que tu peux reprendre ton split pour ta colle (le tiret du six)

http://php.net/manual/fr/function.explode.php
http://php.net/manual/fr/function.implode.php

Après ça tu peux faire un affichage avec un echo

ou placer cette requête ?

select DATE_FORMAT(date_post, '%d-%m-%Y') as date_post from ...


est à mettre dans la base SQL ou dans une page PHP ??

Dans une requête sql.

Normalement tu ne devrais pas effectuer un affichage à partir de données "post". Cela crée des problèmes si l'utilisateur utilise par la suite la commande retour arrière du navigateur.

Tu as aussi une solution très simple et qui marche très bien:
lorsque tu récupères ta variable avec la valeur 2015-02-05, tu splites... contaténation... implode

Nan, c'est quoi ce bricolage ? Quand il existe des fonctions internes, on les utilise ! Donc pour une requête qui retourne des dates on utilise en premier lieu les fonctions date de mysql comme le suggère tof73 ou sinon les fonctions date de php.

Pour convertir des dates avec des lettres en français on peut utiliser strftime

$sql = "SELECT *,DATE_FORMAT(date_post, '%d/%m/%Y à %Hh:%i.' ) AS 'date_post' FROM tiny";

OK çà roule !
Merci et au plaisir =D>

Bonjour,

Quand il existe des fonctions internes, on les utilise !

Est-ce vraiment nécessaire?

J'ai essayé votre méthode qui marche très bien elle aussi (fonction setlocale, puis strftime pour avoir un timestamp formaté,
avec devant la fonction utf8_encode pour éviter d'avoir des losanges à la place des accents).

Je peux donc soit effectivement utiliser votre méthode, soit la mienne avec les fonctions explode et implode.
Elles marchent toutes les deux parfaitement, je les ai vérifié toutes les deux, mais pourquoi AB me recommandes-tu si fortement
de condamner la mienne pour un résultat absolument identique?

Quand il existe des fonctions internes, on les utilise !

Est-ce vraiment nécessaire? [...]
Elles marchent toutes les deux parfaitement, je les ai vérifié toutes les deux, mais pourquoi AB me recommandes-tu si fortement
de condamner la mienne pour un résultat absolument identique?

En règle général, les fonctions internes de PHP sont bien plus efficaces en terme de rapidité, de portabilité et de lisibilité.
- C'est plus rapide car c'est optimisé et codé en C.
- C'est plus portable d'une plateforme à l'autre, car certaines plateformes (Windows/Linux/32/64 bits/etc...) peuvent se comporter légèrement différemment or les fonctions internes gèrent les cas particuliers (même si dans ce cas précis avec implode et explode il y a peu de risque).
- C'est plus lisible car si quelqu'un repasse derrière ton code 3 ans plus tard, il est plus simple de comprendre à quoi sert une ligne de code qui utilise un date_format ou un strtotime plutôt qu'un explode/implode pour lequel il faut lire les paramètres et voir dans quel ordre ils sont pour comprendre le fonctionnement.

Merci @rthur pour ces explications. C'est très intéressant et utile de le savoir.
Je remplace donc mon code par les fonctions internes

@niconicochan

Salut,

Oui et en plus de ce qu'a dit @rthur, il s'agit dans ce cas particulier de fonctions mysql. Or il est intéressant de faire le maximum possible avec mysql car c'est autant de travail en moins que devra faire php. En plus on ne passe pas une vie de développeur sans avoir besoin de s'intéresser à ces fonctions date de mysql car dans d'autres cas il serait difficile de s'en passer (pour faire des tris complexes sur des dates par exemple).

L'exemple de tof73 était donc à la fois plus performant et en même temps plus pédagogique. Si tu étais intervenu avant sa réponse, je n'aurais rien dit, mais comme tu es intervenu après (avec un conseil fonctionnel mais moins avisé), ma petite réflexion était pour souligner l'ordre de préférence

Sinon les fonctions DATE de php sont également intéressantes et puissantes depuis php 5.2 ou 5.3. Donc si on avait pas pu traiter le problème avec mysql on aurait utilisé les fonctions date de php. Mais bon ta solution fonctionne (j'ai fait pareil que toi à mes débuts ), juste par efficacité et pédagogie il vaut mieux conseiller le plus optimisé.

Un autre exemple est l'utilisation d'une fonction comme FILTER_VALIDATE_EMAIL. Le format des email n'est pas immuable, il peut y avoir des évolutions. Si tu fais un équivalent en dur dans ton code pour valider les mails, il te faudrait suivre l'évolution des formats de mail pour mettre ta fonction à jour au fil du temps. En utilisant la fonction interne de php les évolutions seront prises en compte automatiquement en passant d'une version de php à une autre.

Donc tout ça additionner à une meilleure rapidité fait qu'on peut dire d'une manière générale qu'il vaut mieux utiliser les fonctions internes quand elles existent

Bonjour AB,

Pas de problème.
Je me suis permis d'intervenir car je savais que si ma solution n'était pas idéale, quelqu'un de plus expérimenté
le ferait savoir, et que du coup ça pourrait profiter à tout le monde, à moi comme à la personne qui a écrit le message.
Si au contraire elle convenait bien, ça aurait toujours au mieux profité à celui qui a écrit le message.
Donc ça apporte que du bon à tout le monde, c'est ce que je trouve super sur ce forum

Du coup, ça a remis en question une partie de ma programmation que je souhaite maintenant améliorer.
Entre temps, j'ai rencontré un problème avec la fonction strftime.
Je pense que c'est pas mal que j'en parle à la suite de ce message car ça va dans la continuité du même sujet.

Dans une bdd, j'ai des dates entrées sous le format classique 2015-02-12 (pour prendre la date d'aujourd'hui) que je souhaite garder.
Je récupère une date pour l'afficher dans un champs de formulaire au format 12 février 2015, ce qui marche très bien avec la fonction strftime
(qui remplace donc mon explode et mon implode).
En l'occurrence, il s'agit d'un formulaire de validation permettant de modifier des données saisies dans un autre formulaire.
Maintenant, dans mon fichier de traitement de formulaire, j'utilise toujours un explode et un implode pour la manipulation inverse.
Je m'explique, si l'utilisateur a par exemple changé la date 12 février 2015 par 23 février 2015 dans le formulaire,
il me faut formater 23 février 2015 par 2015-02-23 pour remplacer une date par la nouvelle date dans la bdd.
Là j'ai une difficulté: le strftime semble pas bien gérer la manipulation inverse, à moins que c'est moi qui n'ai pas compris quelque chose d'essentiel.
Pour identifier et résoudre le problème, j'ai créé un page avec un code rudimentaire écrit en php:

<?php
header('Content-Type: text/html; charset=UTF-8');
$date='16 mars 2015'; 
/* $date représente une date qui a pu être modifiée par l'utilisateur 
et que je récupère dans ce format en haut de ma feuille de traitement de formulaire. */
setlocale(LC_TIME, 'fra_fra');
echo $date.'<br \>';

//je veux mettre $date dans un format avec que des chiffres.
$date_format_chiffres=utf8_encode(strftime("%Y-%m-%d",strtotime(htmlentities($date, ENT_QUOTES, 'UTF-8'))));
echo $date_format_chiffres;
?>

Le navigateur ressort:
16 mars 2015
2015-03-17

Premier problème constaté: dans la conversion au nouveau format un jour a été ajouté.
Je ne comprends pas du tout la raison.

Maitenant je prends un autre exemple, avec le même code mais une autre date:

<?php
header('Content-Type: text/html; charset=UTF-8');
$date='16 février 2015'; 
/* $date représente une date qui a pu être modifiée par l'utilisateur 
et que je récupère dans ce format en haut de ma feuille de traitement de formulaire. */
setlocale(LC_TIME, 'fra_fra');
echo $date.'<br \>';

//je veux mettre $date dans un format avec que des chiffres.
$date_format_chiffres=utf8_encode(strftime("%Y-%m-%d",strtotime(htmlentities($date, ENT_QUOTES, 'UTF-8'))));
echo $date_format_chiffres;
?>

Le navigateur ressort:
16 février 2015
1970-01-01

Deuxième problème constaté: dans la conversion au nouveau format la date
gardée est celle du jour à partir duquel le timestamp est compté.

Quand j'ai une nouvelle date pour $date, je me retrouve avec un des deux problèmes
énoncés, et dont je ne comprends pas la cause.
Quelqu'un peut-il m'aider?

strftime c'est pour l'affichage.

Regarde des exemples de formulaires qui permettent de rentrer des dates, tu verras que tous demandent un format numérique de type jj/mm/aaaa. Il peut y avoir des variantes dans le format mais c'est toujours du numérique qui est demandé.

Donc tu te complique la vie inutilement et en plus celui de l'utilisateur car c'est plus vite fait d'écrire "15/02/2015" que "15 février 2015". Pour encore plus de confort dans la saisie on peut utiliser des outils comme datepicker de jquery ce qui permet d'éviter de faire la saisie au clavier.

...
Pour compléter ma précédente réponse, une fois les valeurs numériques récupérées tu peux utiliser DateTime::createFromFormat en indiquant le format et le séparateur utilisé pour récupérer une date que tu pourras insérer en bdd.

$test_date = '15/02/2015';
$format = 'd/m/Y';
$date = DateTime::createFromFormat($format, $test_date);
echo $date->format('Y-m-d H:i:s');

Pour les valeurs textuelles cette fonction ne comprend que l'anglais (c'est peu gênant car de toutes façon la saisie textuelle n'est pas très pratique comme dit plus haut).

strftime c'est pour l'affichage.

C'est bien ce que je craignais, en voyant que toute fonction strftime est toujours
précédé d'un echo dans les différents tutos et messages utilisateurs qu'on peut trouver...

Mais en tout cas c'est très clair: si ce que je cherche à faire est impossible à faire,
du moins dans l'état actuel de développement du langage php, ça repond
parfaitement à mon interrogation.
Je te remercie

Dans mon cas, l'affichage de la date dans un format avec des lettres était sympa,
car par exemple 05/02/2015 se lit moins facilement que 05 février 2015:
en effet 05 et 02 étant tous deux des nombres à deux chiffres, il devient nécessaire
d''analyser la place de chacun de ces nombres dans la date pour en déduire
si on parle d'un 05 février ou d'un 02 mai, effort dispensé à l'utilisateur
qui lit 05 février 2015. Je trouve aussi que rajouter des lettres donne
un côté moins froid, moins neutre.

Pour ce qui est de l'effort à la réécriture de la date, dans mon cas il s'agit d'un
formulaire de validation, donc disons que l'utilisateur va avoir besoin de corriger cette
date, aller à vue de nez, peut-être seulement 1 fois sur 30, et il peut avoir aussi l'opportunité
de réécrire en chiffres et non en lettres le mois à modifier. Par contre, je suis d'accord, un mois en lettres
prend un peu plus de temps à effacer qu'un mois sur deux chiffres.
Mais cet inconvénient avec une probabilité de 1/30 ne vaut pas selon moi l'intérêt
de l'avantage avec une probabilité de 29/30.

Bon, vous direz peut-être que je coupe les cheveux en quatre, mais je trouve ça dommage
que php ne me permette pas de faire ce que je veux faire.
Peut-être que ce sera possible dans le futur.
Je le dis car je pense que le retour utilisateur est important,
même si ce dernier a juste un petit niveau comme moi.
A condition bien sûr que la remarque soit constructive

En tout cas pour moi tout est bon, un grand merci