utiliser la fonction SQL TIMESTAMPDIFF plutot qu'une expression compliquee. On doit pouvoir optimiser aussi les xxx_relatifs mais c'est à creuser
Details: http://core.spip.org/projects/spip/repository/revisions/20389
je reviens viteufé sur ce commit pour 2 trucs :
- TIMESTAMPDIFF c'est mysql5 minimum
ah mince, j'ai pas vu ça 
On a encore des mysql 4.x dans la nature je suppose ?
- les résultats retournés par cette fonction diffèrent
*dans certains cas* de ceux retournés par l'ancienne fonction.
voir : http://www.circaete.net/irc/critere_age.jpg
Oui, ça j'ai vu. Il y a deux sources d'écart :
- le fait que le résultat de l'ancienne fonction est non entier, alors que l'âge est présupposé être un nombre de jour entier
- le fait que l'ancienne fonction fait des approximations sur le nombre de jours par mois, par an etc... J'ai regardé un peu en détail et en fait c'est le résultat de l'ancienne fonction, avec ses approximations, qui était toujours faux.
Chose plus embêtante, quand tu inversais les deux dates, l'âge n'était pas symétrique, car le LEAST prends le plus petit, c'est à dire "le plus grand en valeur absolue" quand l'âge est négatif.
il y a de forts risques de causer des incompréhensions lors
de l'utilisation du critère {age > 0} qui devra donc être corrigé
en {age >= 0} (cas de 0.816018518 qui devient 0) mais qui du coup
ne veut plus dire la même chose.
Oui je concède qu'il peut y avoir des petits écarts à la marge. Je pense pas que dans le cas que tu donne il faille changer le critère : ce qui est troublant c'est qu'un résultat ressorte auparavant alors qu'il avait moins de 1j d'âge. Mais peut-être je me trompe (peut-être parce que j'ai toujours cru que l'age était un nombre de jours entier.
(et je n'ai pas compris la logique du mode d'arrondi de la fonction)
Je n'ai pas tout compris non plus. J'ai testé avec tout format de date, y compris incomplète, etc et je n'ai pas trouvé de cas où l'ancienne fonction était mieux que TIMESTAMPDIFF.
Du coup je n'ai pas cherché à comprendre dans quel cas laquelle des 3 expressions était la plus pertinente etc.
Bon c'était peut-être pas malin d'avoir intégré ça dans le trunk, c'est la lenteur de l'ancienne expression sous sqlite qui m'a un peu forcé la main, mais si ça casse des choses on roll-back.
Cédric
