Je constate un bug sur les ages au moins sur SPIP 3.0.8 [20422]
Dans le plugin seances que je porte sur spip3, j'ai un champ date_seance
que j'ai défini comme une date de façon à pouvoir utiliser les critères
age_seance > 0 ou <0 ou = 0 pour le jour
en spip2 pas de soucis pour les seances du jour
avec le même code en spip3 il me sort celles du jour et celles du
lendemain.
pour la même boucle
<BOUCLE_b (SEANCES articles){id_rubrique =1}{age_seance=0}>
<h4>#TITRE</h4>
[(#DATE_SEANCE|affdate_jourcourt) -
][(#DATE_SEANCE|heure_seance)<br />]
</BOUCLE_b>
Entre les deux versions de spip le calcul de ce critère a été modifié
on avait en spip2
SELECT L1.titre, seances.date_seance
FROM spip_seances AS `seances`
INNER JOIN spip_articles AS L1 ON ( L1.id_article = seances.id_article )
WHERE ((L1.id_rubrique = 1))
AND
(LEAST((UNIX_TIMESTAMP(NOW())-UNIX_TIMESTAMP(seances.date_seance))/86400
{age} retourne l'age d'un contenu arrondi au nombre de jour inférieur
Donc jusqu'à 24h après la date initiale age=0
puis jusqu'à 48h age=1
etc…
Le calcul de {age} a en effet été modifié en SPIP 3.0.8, c'est peut être une erreur de l'avoir fait dans une version mineure et il est possible que j'ai sous-estimé l'impact de la correction. Le calcul antérieur était compliqué, couteux, et pas très clair car reposant sur 3 expressions dont on prenait la valeur inférieure (en particulier les âges n'étaient pas symétriques entre positif et négatif).
Le besoin que tu exprimes : "afficher tous les evenements du même jour" est exactement ce à quoi sert le critère {jour_relatif} et tu obtiendras le bon résultat avec {jour_relatif_seance=0}.
Après reflexion :
- avant {age} retournait exactement 0 pour toutes les dates entre le début de la journée et maintenant,
- maintenant {age} retourne 0 pour toutes les dates entre il y a 24h et dans 24h et il n'est plus possible d'avoir "aujourd'hui, jusqu'à maintenant".
Peut-être {age} devrait avoir la résolution d'une 1heure et non d'une journée (donc exprimé en nombre de jours, mais chiffre à virgule).
Il serait ainsi possible de retrouver "aujourd'hui, jusqu'à maintenant" avec {jour_relatif=0}{age>0}, ou aussi "a partir de maintenant, jusqu'à la fin de la journée" avec {jour_relatif=0}{age<0} (dans les deux cas, le "maintenant" serait pris avec une imprécision d'1h).
{age} retourne l'age d'un contenu arrondi au nombre de jour inférieur Donc
jusqu'à 24h après la date initiale age=0 puis jusqu'à 48h age=1 etc…
Le calcul de {age} a en effet été modifié en SPIP 3.0.8, c'est peut être
une erreur de l'avoir fait dans une version mineure et il est possible que
j'ai sous-estimé l'impact de la correction. Le calcul antérieur était
compliqué, couteux, et pas très clair car reposant sur 3 expressions dont
on prenait la valeur inférieure (en particulier les âges n'étaient pas
symétriques entre positif et négatif).
Le besoin que tu exprimes : "afficher tous les evenements du même jour"
est exactement ce à quoi sert le critère {jour_relatif} et tu obtiendras
le bon résultat avec {jour_relatif_seance=0}.
OK merci des précisions. j'utilisais age=0 jusqu'à maintenant et ça
fonctionnait, donc faudra corriger. à partir de spip 3.0.8
Après reflexion : - avant {age} retournait exactement 0 pour toutes les
dates entre le début de la journée et maintenant, - maintenant {age}
retourne 0 pour toutes les dates entre il y a 24h et dans 24h et il n'est
plus possible d'avoir "aujourd'hui, jusqu'à maintenant".
Pour les évenements de la journée je m'en sortais aussi quelques fois
par :
declarer avant la boucle
[(#SET{aujourdhui,[(#DATE|affdate{'Y-m-d'})]})]
et pour la boucle le critère
{date_seance like #GET{aujourdhui}%}
C'est surtout le comportement pour la valeur 0 qui est modifié j'ai
l'impression et ce serait bien de le préciser quelque part.
ce n'est pas que le comportement de 0 qui est affecté, mais c'est
sur lui que les différences de retour sont évidentes.
de fait le calcul des arrondis de la nouvelle fonction tient
compte de la valeur d'un jour. en dessous de 1 elle retourne toujours 0
la question est de savoir pourquoi 29,4368 donne 30 d'un côté (partie
entière plus 1) alors que 36,4368 (mêmes décimales) donne 36 de l'autre
(partie entière plus 0).
il est concevable de penser que la fonction tient compte du mois
(savoir s'il compte 28, 29, 30 ou 31 jours) pour arrondir son résultat…
