Bonjour,
sur des sites où j’utilisais le champ « date de rédaction antérieure », le passage en 4.1 (ici en 4.1.7) donne ceci lorsque je saisi «1914» : «21/01/2013»
C’est bizarre qu’il n’y ait pas eu d’autres remarques
Oui, c’est « normal » car la date est normalisée, il faut donc saisir celle-ci sous la forme dd/mm/yyyy, a fonctionnait avant en utilisant une date du style 1914 ? (je ne pense pas)
salut b_b
Le 21 janv. 2023 à 21:31, b_b via Discuter de SPIP noreply@discuter.spip.net a écrit :
Oui, c’est « normal » car la date est normalisée, il faut donc saisir celle-ci sous la forme dd/mm/yyyy, a fonctionnait avant en utilisant une date du style 1914 ? (je ne pense pas)
c’était bien le cas, le site passé en 4.1 existe depuis 2010 et plus de 5000 articles l’utilisent ainsi que les boucles qui vont avec (#DATE_REDAC|annee) : https://cartoliste.ficedl.info/
On pouvait mettre “1914”. Maintenant, il faudrait mettre 01/01/1914 ou n’importe quelle date de l’année voulue. C’est ce que le rédacteur principal a fait sans remonter le changement.
en allant voir le site, je trouve qq articles (assez peu) passés faussement en 1970, dont ceux daté de 1av.J.-C. :-).
Ça a l’air d’être des erreurs de frappe versus unix
https://cartoliste.ficedl.info/spip.php?page=date
un autre migré en spip vers 2002 avec presque 10’000 articles de même. Il est encore en 3.2 et affiche bien “novembre 2022” pour une saisie/encodage “11/2022” avec (#DATE_REDAC|affdate_mois_annee) :
ici, si je passe en v4 il faudra saisir “01/11/2022” au lieu de “11/2022” ?
sur d’autre sites j’ai peut-être fait un meilleur choix en utilisant des mot-clés pour les années lorsque le jour et le mois n’étaient pas utiles (car souvent inconnus).
Claude
Sur une 3.2, c’est bien ça ? Ça vient peut-être du changement de lib pour le dateur en 4.x.
Ça sent le bug avec un système ou PHP tourne en 32bits et pas 64 bits cf :
The valid range of a timestamp is typically from Fri, 13 Dec 1901 20:45:54 UTC to Tue, 19 Jan 2038 03:14:07 UTC. (These are the dates that correspond to the minimum and maximum values for a 32-bit signed integer.) For 64-bit versions of PHP, the valid range of a timestamp is effectively infinite, as 64 bits can represent approximately 293 billion years in either direction.
bonjour,
Oui, c’est une 3.2.
Autant lorsque seule l’année compte, je peux,utiliser le bon filtre, autant pour un site ou le mois compte, c’est complètement différent.
j’ai 1922 lorsque le mois est inconnu et avril 1922 ou septembre… lorsque je connait le mois de parution.
avec un filtre, je me retrouve à na pas savoir choisir le mois lorsqu’il est inconnu ou à tout mettre autoritairement en janvier (ou autre mois) ce qui fausse tout.
les 1avant JC sont des erreurs de saisies que je n’ai pas réussi à isoler
Quand au php 7.4, chez Infomaniak 32 ou 64, je ne sais pas ni ne sais contrôler je suppose.
Claude
correction 8.0 pour le site en spip 4.1
Bonjour,
Je reviens sur cette discussion.
J’ai plusieurs sites spip 3.2 que je ne peux pas encore passer en spip 4 justement pour cette question de DATE_REDAC qui a évolué et qui donc casse (?) mes sites l’utilisant.
Voici des captures qui montrent l’ancien fonctionnement qui a peut-être sembler non conforme aux normes ou à la logique mais qui m’ont permis de construite des sites et de classer des milliers d’articles depuis plus de 20 ans (encore que de mémoire DATE_REDAC n’était pas né de suite et que j’ai probablement du faire une passe pour reprendre les premiers articles
Donc est-il impossible de revenir à l’ancien fonctionnement ?
Si des arguments bétons assurent que c’est impossible, je veux bien refaire une passe sur tous les articles de ces sites et revoir les squelettes mais je suis bien incapable d’écrire un plugin pour un champ date équivalent au précédent.
Sans coder un plugin, tu peux peut-être juste utiliser champs extra et champs extra interface pour rajouter un champ annee_cequetuveux.
Et un coup de PHPMyAdmin pour remplir ce champ avec la valeur de Date rédac antérieure.
merci,
mais quid de :
1/ faire accepter la saisie
2/ faire accepter l’affichage (là, les filtres dates devraient fonctionner) lorsqu’une date complète est défaillante ou une date est incomplète (je ne sais pas comment on dit)
Claude
j’ouvrirais plus tard un fil sur pouvoir dater des bornes de vie pour des biographies (né en décembre 1873 sans connaitre le jour, mort après 1905) 
bonjour, nouveau retour :
le champ date de champs extras ne supporte pas les dates 06/1888 ou 1888
quant à 00/06/1888 ça devient 31/05/1888
ce n’est donc pas utilisable pour remplacer le champ #DATE_REDAC
Je ne sais toujours pas pourquoi le fonctionnement de ce dernier champ a changé
Claude
A mon avis c’est simplement que mysql est devenu plus strict, et spip n’y est pour rien. Par contre si mysql est devenu plus stricti, peut être qu’il prévoit désormais la possibilité de date floue… auquel cas on pourrait modifier champs extras pour gérer cela.
Il te faut probablement utiliser un champ texte, avec une regexp de validation spécifique.
Et sur le pourquoi ça change, bah un champ date (en sql) ne tolère plus par défaut des dates avec des 00, ce qui servait à faire des dates floues il me semble tel que 2023-00-00 …
merci des réponses, Maïeul et Matthieu
le champs texte est à étudier (de même que construire une regexp)
mais un champ date floue dans champ extras serait encore plus simple, c’est vrai
Entretemps j’avais essayé de comparer puis de changer des fichiers (prive/formulaires/dateur + dater.html et dater.php) de spip 4 par des 3.2 pour voir à essayer de remonter au changement, pas d’effet probant. Si la raison vient de Mysql, c’était vain.
Du coup, je viens de regarder un site en 4.1.10 (chez lautre) et le fonctionnement y a été gardé : 06/2023 donne juin 2023 : php7.4.33 (pas de 8.0 ou 8.1 mais seulement 8.2 dispo) et MariaDB 10.1.48-MariaDB-0+deb9u2 - Debian 9.13
Les sites 4.1.10 qui me bloquent sont sur Infomaniak MySQL 5.7
En fait peut être pas… ça semble autorisé par défaut pourtant
https://dev.mysql.com/doc/refman/8.0/en/date-and-time-types.html
I don’t know !
Yaurait aussi la possibilité d’outrepasser certains blocages de MYSQL en modifiant SQL_MODE dans ton fichier d’options
https://dev.mysql.com/doc/refman/5.7/en/sql-mode.html#sqlmode_allow_invalid_dates
mais encore faut il que le javascript de la librairie du picker (si ça y passe) et le php de spip laissent aussi passer, ensuite…
SPIP utilise par défaut set sql_mode='' dans son API mysql (test basé sur _MYSQL_SET_SQL_MODE qui est true par défaut).
bonjour,
je reviens car ça se complique.
J’ai passé tous mes sites de MySQL à MariaDB → pas de différence
Je suis redescendu de php 8.1 à 7.6 → pas de retour à l’ancien fonctionnement
le type de base ou la version de php ne semblent donc pas jouer
le passage de spip 3.2 à 4.1 ou 4.2 est bien le point commun du changement de comportement
sauf que… !
tous les tests ont été fait avec Firefox et que lorsque je fait un test avec Brave, même en php 8.1 et spip 4.2.4, l’ancien comportement (2023, mars 2023, …) est conservé
je ne sais si c’est une piste, mais je peux enfin passer mes derniers sites en spip4
Claude
On me propose de tester sur Chrome mais je n’ai pas
du coup, toujours sur MacOs je teste sur Opéra et Safari : pas de problème (pour moi)
Il y a donc un problème seulement (apparemment) sur Firefox (102.13.Oesr) avec ce passage à Spip 4
on (encore lui !) me suggère un problème d’interprétation du HTML par ce dernier