C'est un peu long à expliquer, et en plus je ne suis pas forcément au top sur les dernières versions de mysql.
Grosso-modo :
a) Mysql affiche et stoque des données à la seconde près, mais bosse en interne sur des microsecondes.
b) Sauf indications contraires la première colonne d'une table au format timestamp est forcément auto-initialisée/auto-updatée. Si vous empéchez ceci, la colonne suivante au format timestamp récolte de l'auto initialisation/auto-update par la suite etc.
CF https://linuxfr.org/nodes/89781/comments/1327695 (oui c'est pas beau de s'auter citer, mais là c'est vraiment pile poil le truc qui explique et on gagne du temps)
c) La valeur 0 dans un timestamp est très particulière, par défaut elle est interdite (donc renvoit un résultat faux quoi qu'il arrive) sauf si on autorise les dates à 0.
d) Par défaut toujours un timestamp ne peut pas être null.
A partir de là il peut se passer pleins de choses suivant le connecteur que tu utilises :
1- Quand il n'y a pas d'index, la comparaison se fait sur des entiers longs (normalement). Mais quand il y a un index pour une raison x,y ou z la comparaison se fait sur des strings. Et là tout peut se produire. En fait le problème peut même venir de ton .0 qui n'existera pas dans ton format de base. Et en chaine on a bien '2012-05-03 08:00:00.0'
Essaye de gicler le .0 et regarde ce qu'il se passe. C'est l'hypothèse la plus probable.
2- Autre possibilité, OVH a modifié le format de stockage des timestamp (comme il est possible de le faire depuis la 5.6.4 et peut être sur les versions précédentes avec les backports), et comme tu demandes explicitement les dizièmes de secondes il te stocke en décimal (ou pire en flotant). A l'affichage ca ne se voit pas car MySQL continue a ne prendre en compte que l'arrondi à la décimale supérieure, mais à la comparaison ca fache. Il manque quelques dizièmes de secondes pour que ca passe.
Pour valider il suffit de faire un select de la date avec un cast sur un décimal et de regarder sil y a bien que des 0 dans la partie décimale. Moins probable mais possible.
3- Ton connecteur interprête la requète différamment suivant qu'il s'agisse d'une colonne avec index ou non, et quand il y a un index il décide de forcer la comparaison directement sur le type timestamp - et là c'est le drame, la comparaison renvoit un timestamp à 0, qui est interdit => comparaison forcément fausse. Très improbable, csi c'est le cas il y a un gros bug dans le connecteur.
[^] # Re: Le bug c'est la requete
Posté par Kaane . En réponse au journal Aujourd'hui, petit bug d'un serveur MySql d'OVH. Évalué à 2.
C'est un peu long à expliquer, et en plus je ne suis pas forcément au top sur les dernières versions de mysql.
Grosso-modo :
a) Mysql affiche et stoque des données à la seconde près, mais bosse en interne sur des microsecondes.
b) Sauf indications contraires la première colonne d'une table au format timestamp est forcément auto-initialisée/auto-updatée. Si vous empéchez ceci, la colonne suivante au format timestamp récolte de l'auto initialisation/auto-update par la suite etc.
CF https://linuxfr.org/nodes/89781/comments/1327695 (oui c'est pas beau de s'auter citer, mais là c'est vraiment pile poil le truc qui explique et on gagne du temps)
c) La valeur 0 dans un timestamp est très particulière, par défaut elle est interdite (donc renvoit un résultat faux quoi qu'il arrive) sauf si on autorise les dates à 0.
d) Par défaut toujours un timestamp ne peut pas être null.
Il est bon de lire aussi le mode de comparaison de timestamp chez mysql, qui vaut le détour : http://dev.mysql.com/doc/refman/5.0/en/using-date.html
A partir de là il peut se passer pleins de choses suivant le connecteur que tu utilises :
1- Quand il n'y a pas d'index, la comparaison se fait sur des entiers longs (normalement). Mais quand il y a un index pour une raison x,y ou z la comparaison se fait sur des strings. Et là tout peut se produire. En fait le problème peut même venir de ton .0 qui n'existera pas dans ton format de base. Et en chaine on a bien '2012-05-03 08:00:00.0' Essaye de gicler le .0 et regarde ce qu'il se passe. C'est l'hypothèse la plus probable.
2- Autre possibilité, OVH a modifié le format de stockage des timestamp (comme il est possible de le faire depuis la 5.6.4 et peut être sur les versions précédentes avec les backports), et comme tu demandes explicitement les dizièmes de secondes il te stocke en décimal (ou pire en flotant). A l'affichage ca ne se voit pas car MySQL continue a ne prendre en compte que l'arrondi à la décimale supérieure, mais à la comparaison ca fache. Il manque quelques dizièmes de secondes pour que ca passe.
Pour valider il suffit de faire un select de la date avec un cast sur un décimal et de regarder sil y a bien que des 0 dans la partie décimale. Moins probable mais possible.
3- Ton connecteur interprête la requète différamment suivant qu'il s'agisse d'une colonne avec index ou non, et quand il y a un index il décide de forcer la comparaison directement sur le type timestamp - et là c'est le drame, la comparaison renvoit un timestamp à 0, qui est interdit => comparaison forcément fausse. Très improbable, csi c'est le cas il y a un gros bug dans le connecteur.