[SPIP Zone] Boucle CONDITION et critère {si..} comparaison de dates problèmatique

Bonjour,

soit ceci :

#SET{Date1,10-04-2017}
#SET{Date2,21-04-2017}

    <BOUCLE_test(CONDITION){si #GET{date1}|>={#GET{date2}}}>
    vrai
    </BOUCLE_test>
    faux
    <//B_test>

La boucle retourne 'vrai' alors qu'elle devrait retourner 'faux' puisque date1 est bien inférieure à date2...

des idées ?

T.

Le 21 avril 2017 à 16:09 :

Bonjour,

Salut T. (drozerah)

soit ceci :

#SET{Date1,10-04-2017}
#SET{Date2,21-04-2017}

    <BOUCLE_test(CONDITION){si #GET{date1}|>={#GET{date2}}}>
    vrai
    </BOUCLE_test>
    faux
    <//B_test>

La boucle retourne 'vrai' alors qu'elle devrait retourner 'faux' puisque
date1 est bien inférieure à date2...

des idées ?

Du point de vu purement informatique, c'est "vrai" : la chaine "10-04-2017"
est classée avant "21-04-2017" puisque "1" est avant "2"
Mais je crois me souvenir que spip a tendance à traiter comme date (mais
quel format ?) les champs ayant pour préfixe "date" ; auquel cas le test
est faux :wink: Par contre je ne sais pas si ça s'applique avec la boucle
(CONDITION)

T.

Le 21 avril 2017 à 16:26, Gildas Cotomale a écrit :

Le 21 avril 2017 à 16:09 :

Bonjour,

Salut T. (drozerah)

soit ceci :

#SET{Date1,10-04-2017}
#SET{Date2,21-04-2017}

    <BOUCLE_test(CONDITION){si #GET{date1}|>={#GET{date2}}}>
    vrai
    </BOUCLE_test>
    faux
    <//B_test>

La boucle retourne 'vrai' alors qu'elle devrait retourner 'faux' puisque
date1 est bien inférieure à date2...

des idées ?

Du point de vu purement informatique, c'est "vrai" : la chaine
"10-04-2017" est classée avant "21-04-2017" puisque "1" est avant "2"
Mais je crois me souvenir que spip a tendance à traiter comme date (mais
quel format ?) les champs ayant pour préfixe "date" ; auquel cas le test
est faux :wink:

Source de mon interprétation :

section : "Formater les dates"
1er paragraphe : "Si les balises #DATE... "

section : "Contexte de date"
1er paragraphe : "SPIP fournit à toutes les boucles un contexte de date"

Par contre je ne sais pas si ça s'applique avec la boucle (CONDITION)

T.

Bonjour,

Le 21/04/2017 à 16:09, drozerah@free.fr a écrit :

#SET{Date1,10-04-2017}
#SET{Date2,21-04-2017}

    <BOUCLE_test(CONDITION){si #GET{date1}|>={#GET{date2}}}>
    vrai
    </BOUCLE_test>
    faux
    <//B_test>

La boucle retourne 'vrai' alors qu'elle devrait retourner 'faux' puisque date1 est bien inférieure à date2...

Et en mettant la même casse partout "Date" au lieu de "date" ?
Parce que là, en toute rigueur, tu compares date1 et date2 qui ne sont pas définies. Je ne sais pas ce que fait le code final mais je ne m'étonne pas que la comparaison renvoie "vrai"...

CM

----- Mail original -----
De: "Gildas Cotomale" <gildas.cotomale@gmail.com>
À: drozerah@free.fr
Cc: "Spip zone" <spip-zone@rezo.net>
Envoyé: Vendredi 21 Avril 2017 16:35:33
Objet: Re: [SPIP Zone] Boucle CONDITION et critère {si..} comparaison de dates problèmatique

Le 21 avril 2017 à 16:26, Gildas Cotomale a écrit :

Le 21 avril 2017 à 16:09 :

Bonjour,

Salut T. (drozerah)

soit ceci :

#SET{Date1,10-04-2017}
#SET{Date2,21-04-2017}

<BOUCLE_test(CONDITION){si #GET{date1}|>={#GET{date2}}}>
vrai
</BOUCLE_test>
faux
<//B_test>

La boucle retourne 'vrai' alors qu'elle devrait retourner 'faux' puisque date1 est bien inférieure à date2...

des idées ?

Du point de vu purement informatique, c'est "vrai" : la chaine "10-04-2017" est classée avant "21-04-2017" puisque "1" est avant "2"

Mais je crois me souvenir que spip a tendance à traiter comme date (mais quel format ?) les champs ayant pour préfixe "date" ; auquel cas le test est faux :wink:

Source de mon interprétation :
http://www.spip.net/fr_article1971.html

section : "Formater les dates"

1er paragraphe : "Si les balises #DATE... "

section : "Contexte de date"

1er paragraphe : "SPIP fournit à toutes les boucles un contexte de date"

Par contre je ne sais pas si ça s'applique avec la boucle (CONDITION)

T.

*************

Je pense que c'est bien une question de formatage de date du coup, comment formater comme il faut selon SPIP puisque la boucle CONDITION fonctionne parfaitement si on remplace les dates par des entiers ?

"Si les balises #DATE... " => ici on utilise un #SET{Date1,10-04-2017} et non pas une balise date, #SET/#GET ne se comportent peut être pas de la même façon qu'une balise #DATE qui possède un contexte de date en BDD et donc un format de date, du coup le critère {si...} n'est peut être pas satisfait avec des variable définies dans un squelette... mais le problème vient peut être d'ailleurs...

Bonjour,

puis en mettant les dates plutôt formatées comme ça

#SET{Date1,20170410}
#SET{Date2,20170421}

Ca n’est pas mieux?

Le 21 avr. 2017 à 16:09, drozerah@free.fr a écrit :

Bonjour,

soit ceci :

#SET{Date1,10-04-2017}
#SET{Date2,21-04-2017}

   <BOUCLE_test(CONDITION){si #GET{date1}|>={#GET{date2}}}>
   vrai
   </BOUCLE_test>
   faux
   <//B_test>

La boucle retourne 'vrai' alors qu'elle devrait retourner 'faux' puisque date1 est bien inférieure à date2...

des idées ?

T.

----
spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone

Mais je crois me souvenir que spip a tendance à traiter comme date (mais
quel format ?) les champs ayant pour préfixe "date" ; auquel cas le test
est faux :wink:

Source de mon interprétation :
La gestion des dates - SPIP

section : "Formater les dates"

1er paragraphe : "Si les balises #DATE... "

section : "Contexte de date"

1er paragraphe : "SPIP fournit à toutes les boucles un contexte de date"

Par contre je ne sais pas si ça s'applique avec la boucle (CONDITION)

T.

*************

Je pense que c'est bien une question de formatage de date du coup, comment
formater comme il faut selon SPIP puisque la boucle CONDITION fonctionne
parfaitement si on remplace les dates par des entiers ?

Pour les dates, il faut privilégier le format ISO : "2017-04-10" (pour le

10 avril) ou "2017-10-04" (pour le 4 octobre) au lieu de "10-04-2017" (ici
l'interprétation dépend de la localisation...)

Noter que le format ISO se transforme simplement en entier quand on ôte le
séparateur (tiret) : "20170410" ou "20171004" En tant que chaîne de
caractères ou entier, le tri et la comparaison sont naturels (et ASCII) :wink:

"Si les balises #DATE... " => ici on utilise un #SET{Date1,10-04-2017} et
non pas une balise date, #SET/#GET ne se comportent peut être pas de la
même façon qu'une balise #DATE qui possède un contexte de date en BDD et
donc un format de date, du coup le critère {si...} n'est peut être pas
satisfait avec des variable définies dans un squelette... mais le problème
vient peut être d'ailleurs...

Bien vu, ce ne sont pas des balise #DATE1 et #DATE2 !

--

♪♫•*¨*•.¸¸❤¸¸.•*¨*•♫♪.♪♫•*¨*•.¸¸❤¸¸.•*¨*•♫♪

Le 21/04/2017 à 16:09, drozerah@free.fr a écrit :

#SET{Date1,10-04-2017}
#SET{Date2,21-04-2017}

    <BOUCLE_test(CONDITION){si #GET{date1}|>={#GET{date2}}}>
    vrai
    </BOUCLE_test>
    faux
    <//B_test>

L'erreur est probablement due au fait que le nom de tes variables contient un chiffre.
Choisis debut et fin, et ça passera mieux,
ou date_debut et date_fin
ou date_un et date_deux
etc

JL