[spip-dev] dates : jour et mois indéfinis

christophe_ld · Novembre 17, 2009, 2:22

bonjour,

au cas où cela n'aurait pas déjà été signalé, avec la version 2.0.10,
[(#DATE|affdate] avec le jour et le mois non définis affiche "1er
2009".

Et, à propos des jours indéfinis pour un article par exemple : est-il
indispensable de corriger le jour indéfini par "1er" ? En effet, je
souhaitais pouvoir afficher "publié le" si le jour est défini et
"publié en" si le jour (et le mois) n'est pas défini, or la correction
0 (ou indéfini) = 1 empêche de tester l'hypothèse. Ou alors il y a un
autre moyen qui m'a échappé...

christophe

denisb1 · Novembre 17, 2009, 2:30

christophe le drean a écrit :

or la correction
0 (ou indéfini) = 1 empêche de tester l'hypothèse. Ou alors il y a un
autre moyen qui m'a échappé...

il faut tester l'existence du jour sur #DATE*
(en base, la valeur est bien à 00)

Payet_Teddy · Novembre 17, 2009, 2:31

Bonjour,

Si tu testes la présence du jour, est-ce que ceci ne fonctionnerait pas :
[(#DATE|jour|oui) publié le]
[(#DATE|jour|non) publié en]

non?

Le 17 novembre 2009 15:22, christophe le drean <christopheld@gmail.com> a écrit :

denisb1 · Novembre 17, 2009, 2:35

Teddy Payet a écrit :

Si tu testes la présence du jour, est-ce que ceci ne fonctionnerait pas :
[(#DATE|jour|oui) publié le]
[(#DATE|jour|non) publié en]

avec une date qui a été entrée en :
nc-juillet-2009

[(#DATE*|affdate)] renvoie : juillet 2009

avec une date qui a été entrée en :
nc-non connu-2009

[(#DATE*|affdate)] renvoie : 2009

fil · Novembre 17, 2009, 2:44

avec une date qui a été entrée en :
nc-juillet-2009

[(#DATE*|affdate)] renvoie : juillet 2009

avec une date qui a été entrée en :
nc-non connu-2009

[(#DATE*|affdate)] renvoie : 2009

Le bug est à corriger dans #DATE, alors ?

-- Fil

Payet_Teddy · Novembre 17, 2009, 2:48

Tiens? Un élément supplémentaire à la doc?

Je m’en occupe de suite…

Autre question pour comprendre. Avec le principe de #DATE*, le résultat avec [(#DATE*|jour|oui)] est toujours “oui” comme me le rappelle christophe pour [(#DATE|jour|oui)]?

Payet_Teddy · Novembre 17, 2009, 2:55

Ça été ajouté à la doc :
http://www.spip.net/ecrire/?exec=articles&id_article=4336

denisb1 · Novembre 17, 2009, 2:56

Teddy Payet a écrit :

Autre question pour comprendre. Avec le principe de #DATE*, le résultat avec
[(#DATE*|jour|oui)] est toujours "oui" comme me le rappelle christophe pour
[(#DATE|jour|oui)]?

c'est du retour sql.

jour retourne '00' dans le cas d'un indéfini (entré avec 'nc')
donc il y a bien un retour
donc |oui == oui

donc.

[(#DATE*|mois|>{00}|oui) [(#DATE*|affdate)]]

denisb1 · Novembre 17, 2009, 2:57

Fil a écrit :

Le bug est à corriger dans #DATE, alors ?

euh...
on tourne en rond là

fil · Novembre 17, 2009, 2:58

Tiens? Un élément supplémentaire à la doc?

Non : c'est un bug, ça ne se documente pas, ça se corrige !

-- Fil

claude_delattre · Novembre 17, 2009, 7:11

il y avait :
http://trac.rezo.net/trac/spip/ticket/1685
j'ai rajouté -- pas très proprement -- un truc que j'avais sous le coude (le temps de retrouver les codes d'accès, donc surtout de les chercher :))
Claude

denisb1 · Novembre 17, 2009, 7:25

Fil a écrit :

Le bug est à corriger dans #DATE, alors ?

les 3 balises
   #DATE
   #DATE_REDAC
   #DATE_MODIF
ne font que retourner champ_sql()

une vérif sur les valeurs de jour et mois
devraient suffire.

*sauf que*

sauf que pg n'accepte pas 2009-12-00 comme valeur
dans ses champs date et corrige en 2009-12-01
(les dates non renseignées stockées en 0000-00-00 00:00:00
par mysql le sont en 0001-01-01 00:00:00 BC par pg)

sauf que à continuer à confondre date et période
on va finir par se casser la binette :
- la date de publication *doit* être une date valide
- ce qu'il faudrait corriger c'est le détournement de
   ce champ (proposer 'nc' et 'non connu' est sans doute une erreur)
   peut-être en proposant un *nouveau* champ exprimant une
   période (dont les bornes seraient par défaut la date
   de publication)
   on pourrait ainsi avoir un champ 'autre_date' qui exprimerait
   soit 'une' date depuis == jusqu'à soit une 'date floue' ou
  'période' (janvier 2003 ; 1988)

claude_delattre · Novembre 17, 2009, 7:49

sur un site recensant des parutions de périodiques, un journal paru le 1er janvier 1895 et en janvier 1895, ce n'est pas la même chose (souvent un quotidien, un hebdo ou un bimensuel dans le premier cas, un mensuel ou un apériodique dans l'autre). Je peux donc tout resaisir en mots clés (un groupe pour les quantièmes, un pour les mois, un pour les ans) mais c'est une perte de compatibilité tout de même -- peut-être inévitable -- (et des boucles infernales à construire). J'utilise surtout la date de publication antérieure.

J'avais le chantier à faire, avec agenda, de lister les périodes de parutions de ces périodiques (un périodique = un article, soit 2'000 articles). J'ai donc, solution intermédiaire, du créer un groupe dédié avec les mots : debut_annee, debut_mois, debut_jour, fin_annee, fin_mois, fin_jour pour gérer l'affichage.

Claude

claude_delattre · Novembre 17, 2009, 9:55

sur un site recensant des parutions de périodiques, un journal paru le 1er janvier 1895 et en janvier 1895, ce n'est pas la même chose (souvent un quotidien, un hebdo ou un bimensuel dans le premier cas, un mensuel ou un apériodique dans l'autre).

la date de publication de spip *n'est pas* la date de publication d'un document-article
recensé dans la base de données de spip.

l'utilisation de l'une pour renseigner l'autre est un détournement.

on est là typiquement dans le cas que je citais.
la date de publication d'un périodique (je ne parle pas de la date d'impression
ou de la mise en kiosque) est une *période* (comme son nom l'indique...) :
semaine du tant au tant, mois de ..., 1er trimestre de telle année, ...

sur un autre site, ce sont des dates de parution de livres ou mars 2009 s'affichait "mars 2009" et 2009 (pas de connaissance du mois) s'affichait "1er 2009" ! On ne peut parler de période d'un livre ?

mais ici, ben non plus, le numéro du 13 janvier n'est pas une période (et n'est pas forcément le journal d'un seul jour) et le numéro de mars succède parfois au numéro de janvier de la même année ou au numéro de décembre de l'année précédente.
Il ne s'agit pas ici de date de "validité" d'un exemplaire. J'écris bien sur la date de sortie (supposée).

Après, j'essaye d'en tirer des périodes : titre paru "entre mars 1982 et 15 juillet 1986". Accessoirement, je suis bloqué aussi par le plugin Agenda qui ne gère pas les dates avant 1902

Le but derrière, dans ce cas, c'est de lister tous les périodiques paraissant à telle ou telle date
par année ce serait possible par mots clés, que 300 de plus à ajouter et même 3600 aux presque 10'000 existants pour affiner au mois
mais c'est pas gagné, ne serait-ce que parce que certains titres on connu plusieurs séries avec des interruptions. Rien n'est parfait.
Bon, ce n'est pas l'objet direct de la discussion et il n'y a peut-être pas de possibilité à mon projet.

Claude

c'est quand même une évidence que (à la différence du 'jour d'après') le jour 0 n'existe pas.

c'est une perte de compatibilité tout de même -- peut-être inévitable -- (et des boucles infernales à construire).

de toute façon, il faudra reconsidérer l'affichage résultant des boucles.

et la correction de la 'balise' seule, ne changera rien au 'critère' associé :
le traitement de #DATE est différent de celui de {date}

perdu je suis

denisb1 · Novembre 17, 2009, 10:57

dlatr a écrit :

sur un autre site, ce sont des dates de parution de livres ou mars 2009 s'affichait "mars 2009" et 2009 (pas de connaissance du mois) s'affichait "1er 2009" ! On ne peut parler de période d'un livre ?

on raisonne en 'date-time' :
livre publié entre le 2009-03-01 00:00:01 et le 2009-03-31 23:59:59

la vrai 'date de publication' (de l'article présentant ce livre)
étant 2009-03-25 12:35:41 (par exemple)

Le but derrière, dans ce cas, c'est de lister tous les périodiques paraissant à telle ou telle date
par année ce serait possible par mots clés, que 300 de plus à ajouter et même 3600 aux presque 10'000 existants pour affiner au mois
mais c'est pas gagné, ne serait-ce que parce que certains titres on connu plusieurs séries avec des interruptions. Rien n'est parfait.
Bon, ce n'est pas l'objet direct de la discussion et il n'y a peut-être pas de possibilité à mon projet.

pour le coup, un ou deux 'champ extra' seraient d'une efficacité
redoutable me semble-t'il...

perdu je suis

succintement :
imaginons que tu ais entré 'nc-janvier-2005' comme date d'un article

mysql enregistrera '2005-01-00 00:00:00'

une fois corrigée (!) #DATE|affdate afficherait 'janvier 2005' (cool)

mais imaginons (encore) que tu veuille les dates postérieures (dans ton
esprit donc à partir du 1er février 2005)

la correction de la 'balise' #DATE (son affichage) n'aura rien changé au calcul du 'critère' {date} qui considèrera que '2005-01-02' est bien
supérieur à '2005-01-00' (ou '2005-01-01' pour postgresql)...

ce que je veux dire, c'est que la correction d'un 'affichage'
ne corrigera pas l'erreur (je me répète) de donner la possibilité
d'une 'date impossible'.

claude_delattre · Novembre 18, 2009, 10:13

dlatr a écrit :

sur un autre site, ce sont des dates de parution de livres ou mars 2009 s'affichait "mars 2009" et 2009 (pas de connaissance du mois) s'affichait "1er 2009" ! On ne peut parler de période d'un livre ?

on raisonne en 'date-time' :
livre publié entre le 2009-03-01 00:00:01 et le 2009-03-31 23:59:59

la vrai 'date de publication' (de l'article présentant ce livre)
étant 2009-03-25 12:35:41 (par exemple)

Le but derrière, dans ce cas, c'est de lister tous les périodiques paraissant à telle ou telle date
par année ce serait possible par mots clés, que 300 de plus à ajouter et même 3600 aux presque 10'000 existants pour affiner au mois
mais c'est pas gagné, ne serait-ce que parce que certains titres on connu plusieurs séries avec des interruptions. Rien n'est parfait.
Bon, ce n'est pas l'objet direct de la discussion et il n'y a peut-être pas de possibilité à mon projet.

pour le coup, un ou deux 'champ extra' seraient d'une efficacité
redoutable me semble-t'il...

hum, peut-être pas si simple mais je vais y réfléchir ; je ne suis pas à un an prêt et près

perdu je suis

succintement :
imaginons que tu ais entré 'nc-janvier-2005' comme date d'un article

mysql enregistrera '2005-01-00 00:00:00'

une fois corrigée (!) #DATE|affdate afficherait 'janvier 2005' (cool)

mais imaginons (encore) que tu veuille les dates postérieures (dans ton
esprit donc à partir du 1er février 2005)

la correction de la 'balise' #DATE (son affichage) n'aura rien changé au calcul du 'critère' {date} qui considèrera que '2005-01-02' est bien
supérieur à '2005-01-00' (ou '2005-01-01' pour postgresql)...

ce que je veux dire, c'est que la correction d'un 'affichage'
ne corrigera pas l'erreur (je me répète) de donner la possibilité
d'une 'date impossible'.

ok, lorsque j'ai adopté Spip en 2002 dans ma naïveté de non-informaticien, je ne pensais pas faire *mal*. Après Word, Claris Home Page et Golive, ça semblait fonctionner à ma convenance ; ça c'est beaucoup perfectionné encore depuis mais il y a régulièrement quelques séances de rattrapage pour faire rentrer mes déviances dans le cadre ad hoc

Il y aurait, quoi qu'il en soit, une précision/mise ne garde à mettre dans la doc pour les filtres affdate (ce qu'il semble faire et ce qu'il fait exactement)

Claude

denisb1 · Novembre 18, 2009, 11:11

dlatr a écrit :

je ne pensais pas faire *mal*.

ah mais, je ne voulais pas dire ça du tout du tout !
désolé si c'est le (contre)sens qui se dégage de mon message.

non.
je parlais d'une 'erreur' du côté de spip d'offrir cette
possibilité de détournement.

Il y aurait, quoi qu'il en soit, une précision/mise ne garde à mettre dans la doc pour les filtres affdate (ce qu'il semble faire et ce qu'il fait exactement)

il faudrait surtout reprendre toute la gestion des dates (les critères age_ ...) mais ce n'est pas un petit travail !

pour info, je viens de tester sous pg :
entrer 'nc-non connu-2009' affiche directement dans
le select '1-janvier-2009'
voir http://www.circaete.net/vrac2/dates.jpg
en haut : postgresql
en bas : mysql

fil · Novembre 29, 2009, 10:42

je parlais d’une ‹ erreur › du côté de spip d’offrir cette
possibilité de détournement.

Dans les anciennes versions de SPIP ce détournement n’existait (je crois) que pour la « date de rédaction antérieure » et non pour la « date de publication ». Un truc a dû sauter…

Cela dit il fallait corriger le problème d’affichage :
http://trac.rezo.net/trac/spip/changeset/14770

La difficulté était que normaliser_date servait à la fois :

à passer une date dans l’URL pour faire des critères du type ?date=2008
à afficher une date

dans le premier cas on ne veut pas de -00, dans le second on en voulait.

(à reporter en stable si ça vous semble ok)

– Fil

arno · Novembre 30, 2009, 10:33

Dans mon souvenir aussi. Et c'était exprès: la date de publication est particulièrement sensible, puisqu'elle sert à fabriquer largement la navigation du site, et à faire différents calculs (articles publiés ou non en date antérieure, calcul de la date des rubriques...). Et la différence se justifiait, justement, par la présence de deux dates:
- la date de publication est une date semi-automatique liée à de forts automatismes, et elle représente explicitement la date de mise en ligne sur le site Web (date_redac la complète maintenant, mais son aspect entièrement automatisé rend son utilisation un peu casse-gueule);
- la date de publication antérieure sert explicitement à indiquer une date pour des articles qui ont eu une publication «avant le Web»; peu d'automatismes y sont liés, son but est principalement l'affichage. Et c'est là, justement, qu'on a vraiment besoin de pouvoir afficher «1342», «mai 1734»... c'est certes un «détournement» (Fil avait déjà fait remarquer, à l'époque, qu'on risquait de ne pas être compatible avec autre chose que mySQL.)
- différence liée, d'ailleurs: la date de publication présente, par défaut, un menu déroulant pour sélectionner l'année; l'année de publication antérieure est

=> Perso, ça me semblerait une bonne idée de réintroduire cette différenciation et de ne plus permettre d'utiliser des «dates floues» pour la date de publication et de réserver, à nouveau, cette possibilité, pour la date de rédaction antérieure.

Arnaud