ou en php :

$d=strtotime('today');
$date_du_jour = strftime('%d/%m/%Y %H:%M:%S',  $d );

ca te permet de mettre la date au format que tu souhaites

Je ne suis pas d'accord.
Le format est défini par la base de données (date, datetime, time ou timestamp).
C'est après en exploitant les données stockées dans ta base que tu définis le format d'affichage sinon, avec ce type de méthode, on en arrive à des abérations, la preuve :

ca y est j'ai changé mon champs DATE en VARCHAR et ca passe !!

Merci à tous

et en plus, il est tout content d'utiliser une date en varchar.

l'un et l autre méthode se vallent pjl mais tout dépend de ce qu il veut en faire de cette date.

+1 Pjl

Une date stockée dans un type date ou équivalent est une donnée numérique.
Elle permet des traitements rapides et fiables : tris et calculs.

Stockée sous forme de chaîne de caractères, elle donne une info affichable
mais ne permet aucune autre utilisation et prend plus de place mémoire.

l'un et l autre méthode se vallent pjl mais tout dépend de ce qu il veut en faire de cette date.

Désolé mais je en suis pas du tout d'accord.
Je sais aujourd'hui ce que je vais faire avec les données contenues dans ma BDD mais qu'est ce que l'on va me demander de faire avec dans 5 ans ou plus ?
Si on me demande de sortir les 5 dates les plus récentes, ce n'est pas avec ce format là : DD-MM-YYYY hh:mm:ss que je vais m'en sortir facilement.
Il n'existe qu'UNE et UNE SEULE manière de stocker les dates : utiliser les champs prévus pour.
Le reste n'est que bidouillage et amateurisme.

Maintenant je pense que garder un maximum de souplesse sur les données entrées donne de meilleur liberté au code et au diverses possibilités.
Certe ta base deviens plus lourde mais bon dans le secteur ou je travaille le poid n'est pas un facteur prépondérant.
En revanche cela me permet de développer des outils statistiques bien plus performant que celui que pouvais me donner les entrées sql.
Toutefois je pense que dire :

Le reste n'est que bidouillage et amateurisme.

sonne fortement comme une personne enfermer dans ces lignes de codes et qui ne voit pas plus loin que ce qu'il veut bien voir ... (sans attaque personnelle PJL car je pense que tu es un développeur hors pair)
mais faut bien se dire que si cette fonction php existe c'est qu'on peu l'utiliser
maintenant comme je l ai dit plus haut chacun voit midi a ca porte

Je ne crois pas que ce soit un problème de lourdeur d'application mais d'optimisation. Si en effet tu utilises le bon type de champ par rapport à telle donnée, tu pourras la manipuler d'autant plus facilement que des fonctions internes au SQL sont prévues pour ce type de données.

Un type DATE ou DATETIME ouvre des possibilités de tri, de recherche et de manipulations que tu n'auras pas en mettant à la place par exemple 5 champs INT pour stocker individuellement année, mois, jour, heure et minute. Bien sur que tu pourras faire les mêmes opérations de tri, de classement et les manipulations mentionnées par programmation en PHP, mais tu devras constuire une usine à gaz pour faire un truc qui aurait été infiniment plus rapide et efficace avec une requête SQL : ce faisant, tu accélères le traitement et allèges l'application parce que tu réduis également les échanges client/serveur entre PHP et ton SGBD.

Maintenant je pense que garder un maximum de souplesse sur les données entrées donne de meilleur liberté au code et au diverses possibilités.
Certe ta base deviens plus lourde mais bon dans le secteur ou je travaille le poid n'est pas un facteur prépondérant.
En revanche cela me permet de développer des outils statistiques bien plus performant que celui que pouvais me donner les entrées sql.
Toutefois je pense que dire :

Le reste n'est que bidouillage et amateurisme.

sonne fortement comme une personne enfermer dans ces lignes de codes et qui ne voit pas plus loin que ce qu'il veut bien voir ... (sans attaque personnelle PJL car je pense que tu es un développeur hors pair)
mais faut bien se dire que si cette fonction php existe c'est qu'on peu l'utiliser
maintenant comme je l ai dit plus haut chacun voit midi a ca porte

Justement, à aucun moment, je n'ai parlé de code.
Je ne parle que de stockage de données et je considère que la conception d'une base de données doit être indépendante de tout langage.

Maintenant, si dans certains cas, il est plus intéressant de stocker une date dans un varchar, pourquoi pas mais alors, j'aimerai bien avoir un exemple concret.