Reprise du message précédent :
  ca travaille aujourdhui ?

 
Tu peux m'en dire plus s'il te plait ?

Pour ma date, si je demande à l'utilisateur de la rentrer au format FR et qu'ensuite je fais ça, c'est bon ?
 
INSERT INTO ma_table SET mon_champ_date = STR_TO_DATE('$date', '%Y/%d%m')

Bin perso je ferais le traitement avant la requête ; en fait, tout dépend de ce que tu as dans $date. Si l'utilisateur rentre "youpi" ou fait une erreur quelconque, t'es un peu mort, non ? Donc tu vas certainement faire un contrôle sur ta date et, à la fin du check, tu la passes au format MySQL.
Faut jamais faire confiance à l'utilisateur de toute façon, d'une part parce que l'erreur est humaine et d'autre part à cause des petits malins à la recherche de failles dans ton code

Non, faut faire la conversion à l'insertion, ne serait-ce que pour le cas où tu veux ré-afficher ta date à l'utilisateur avant de faire l'insert.
Tu gères un format d'affichage, qui reste cohérent tout le long, et quand tu lis/écris dans la base tu convertis du format interne de la base à ton format d'affichage.

Euh bin faut faire la conversion juste avant la requête SQL, pas 3 blocs de code plus haut non plus.

bah pourquoi ne pas la faire directement dans la requête, alors, puisque c'est la seule chose qui en a besoin?

Pour vérifier si l'utilisateur a rentré une date dans un format valide, je fais une regxp ?

c'est une option.

Ch'ais pas, ça me semble plus logique de déléguer ça au langage vu que tu fais déjà la plupart des traitements Maintenant ouais, je comprends qu'on puisse avoir un avis différent

Oui, obligatoire On te laisse juste le plaisir de trouver une regexp qui est capable de piger les années bissextilles

Plus sérieusement faut mixer regexp+validation. La première pour vérifier genre un format jour/mois/année, l'autre pour vérifier que c'est une date ok :

$d = array();
if(preg_match('#^(\d{1,2})/(\d{1,2})/(\d{4})$#iuD', $valeur, $d)) {
  if(!checkdate((int)$d[2], (int)$d[1], (int)$d[3])) {
    // erreur
  }
} else {
  // erreur
}

oué, question de point de vue...pour moi ça fait partie de la couche de traduction des données entre ton appli et ta base.

Chuis d'accord avec skeye, sauf à la limite si t'as la classe et que t'acceptes des formats de dates qui ont la classe genre "la semaine dernière" ou "avant-hiers"

Bah dans ce cas-là tu les convertis toujours pas dans le format de la base, mais dans ton format d'affichage - qui en cas de besoin de nouvel affichage sera utilisé et peut être différent de celui natif de la base.
Tu peux avoir un format pour le modèle, un format pour la vue, et un pour le controleur, en fait.

Donc avec correcteur d'orthographe intégré ?  

Ouais

C'te question

u = not chrisbk

Nan mais il m'a transmis la classe internationale

tu confonds avec la chtouille, et ça c'est stiffler qui te l'a refilée.

$d = array();
if(preg_match('#^(\d{1,2})/(\d{1,2})/(\d{4})$#iuD', $valeur, $d)) {
  if(!checkdate((int)$d[2], (int)$d[1], (int)$d[3])) {
    // erreur
  }
} else {
  // erreur
}

 
et là je suis un méchant user et je rentre 19/2/08 et c'est perdu...

j'ai bien compris, c'était pour te donner un nouveau langage a tester, justement

bah dtc, hein.

Thank you, captain obvious. Si je demande 4 chiffre pour l'année, ça me paraît d'une logique inplacable si ça foire avec 2 chiffres

disons que ce serait un "plus" pour l'utilisateur de gérer plusieurs formats d'input...

Ouioui, bien-sûr. Mon truc c'était juste pour montrer qu'un regexp ne suffisait pas à valider une date (à moins d'être fou). Maintenant comme d'hab, on peut pas poster du code sans qu'on te reprenne

M'en fous hein moi, mes seuls clients qui ont besoin d'une saisie de date m'ont donné expressément un format de date à respecter, ça m'arrange...

$d = array();
if(preg_match('#^(\d{1,2})/(\d{1,2})/(\d{4})$#iuD', $valeur, $d)) {
  if(!checkdate((int)$d[2], (int)$d[1], (int)$d[3])) {
    // erreur
  }
} else {
  // erreur
}

Pourquoi ne pas utiliser strptime directement, avec les formats qui nous intéresse, au lieu d'avoir la regex + la fonction ?

 
http://php.net/strptime
 

J'en étais sur
edit : et à part ça ?

'tain des fois ça fait bien peur de lire des trucs pareils...

Bon, pour pas me faire chier j'ai trouvé une technique imparable.
 
Des select

Y a pas moyen de pas avoir ces collate latin1_general_ci quand je fais mon export MySQL ?
 

CREATE TABLE `news_cat` (
  `id` tinyint(3) NOT NULL AUTO_INCREMENT,
  `nom` varchar(30) collate latin1_general_ci NOT NULL,
  `icone` varchar(255) collate latin1_general_ci NOT NULL,
  `image` varchar(255) collate latin1_general_ci NOT NULL,
  PRIMARY KEY  (`id`)
) ENGINE=MyISAM  DEFAULT CHARSET=latin1 COLLATE=latin1_general_ci;

NAN MAIS SURTOUT PAS §§§§
 
Rien de plus chiant que de saisir une date via des select. Souvent les dates sont "câblées" dans les doigts des utilisateurs...
 
 
ET EN PLUS GUESS WHAT §§§§
 
Tu dois toujours te taper la validation de date pour être sûr qu'on ait pas modifié les valeurs lors de la requête HTTP. Et pis avec tes pauvres select, 20€ qu'on peut entrer 31 février

Ouais, enfin là je m'en fou un peu, c'est pas pour un site où j'étais sensé passer trop de temps à la base
 
Par contre mon problème d'export MySQL me fait lui beaucoup plus chier.

C'est quoi le problème d'avoir ces COLLATE ?

Apparemment certains phpmyadmin le supportent pas, j'avais déjà eu le coup sur OVH ou 1AND1 je sais plus.

Quand je créais mes tables via un fichier texte, je mettais pas de collate dedans et tout allait très bien aussi
J'aurais aimé avoir le même résultat à l'export.

Et alors
Pis au pire ça fait 0000-00-00 si le mec fait le malin.

Fin je vois aps trop de cas ou ça fout la merde d'avoir une date aps valide

Et ben alors Ca évite des erreurs c'est tout. Faut être gentil avec l'utilisateur

C'est pas PHPMyAdmin le problème, c'est la version de mysql plutôt...

 
d'autant plus que ma grand mere est née le 29 fevrier 1931