Development #56205
La recherche sur un champ date envoie des dates dans un format qui n'est pas accepté sur postgresql
0%
Description
https://sentry.entrouvert.org/entrouvert/sictiam/issues/48579/?environment=prod
La date entrée "01-01-0090", ce qui est envoyé à postgresql "90-01-01", si on ajoute "00" visiblement ça passe :
bdauvergne=# \d date
Table « public.date »
Colonne | Type | Collationnement | NULL-able | Par défaut
---------+------+-----------------+-----------+------------
coin | date | | |
bdauvergne=# insert into coin (coin) values ('90-01-01');
ERREUR: la colonne « coin » de la relation « coin » n'existe pas
LIGNE 1 : insert into coin (coin) values ('90-01-01');
^
bdauvergne=# insert into date (coin) values ('1090-01-01');
INSERT 0 1
bdauvergne=# insert into date (coin) values ('0090-01-01');
INSERT 0 1
Fichiers
Révisions associées
Historique
Mis à jour par Benjamin Dauvergne il y a plus de 2 ans
Lié à ce vieux ticket python sur le comportement non portable de strftime, https://bugs.python.org/issue13305
Mis à jour par Benjamin Dauvergne il y a plus de 2 ans
- Fichier 0001-sql-fix-serialization-of-dates-with-2-digits-years-5.patch 0001-sql-fix-serialization-of-dates-with-2-digits-years-5.patch ajouté
- Statut changé de Nouveau à Solution proposée
- Patch proposed changé de Non à Oui
Le fix est linux/GLibc only, je ne sais pas si ça a une importance pour nous.
Mis à jour par Frédéric Péters il y a plus de 2 ans
Normalement la saisie se fait par un <input type=date> qui donne yyyy-mm-dd.
Mis à jour par Frédéric Péters il y a plus de 2 ans
Et des infos sentry c'est bien ce qui a été fourni : filter-7-value "0090-08-17".
Je pense qu'ici il faut agir en amont de la requête SQL, qu'il y ait correction plus haut de la saisie (et qu'ainsi ça s'applique aussi aux requêtes en mode pickle).
Mis à jour par Benjamin Dauvergne il y a plus de 2 ans
Frédéric Péters a écrit :
Et des infos sentry c'est bien ce qui a été fourni : filter-7-value "0090-08-17".
Je pense qu'ici il faut agir en amont de la requête SQL, qu'il y ait correction plus haut de la saisie (et qu'ainsi ça s'applique aussi aux requêtes en mode pickle).
Tu parles de ce coin du code :
2056 elif filter_field.type == 'date' and filter_field_value is not None:
2057 try:
2058 filter_field_value = misc.get_as_datetime(filter_field_value).date()
2059 except ValueError:
2060 pass
2061 else:
2062 criterias.append(Equal('f%s' % filter_field.id, filter_field_value))
ici je me dis que si les pickles stockent encore de timetuple ça ne doit pas marcher du tout effectivement mais je ne vois pas le rapport avec le problème actuel.
En fait je ne vois pas bien ce que je peux corriger dans la saisie: on reçoit 0090-08-17, c'est converti en datetime(90, 8, 17, ...), ce qui est toujours bon et au final .strftime('%Y-%m-%d') renvoie '90-08-17' au lieu de '0090-08-17' attendu par postgresql parce que la norme ISO/Open que sais-je ne définit par que %Y doit toujours renvoyer 4 chiffres et les gens de glibc ont trouvé intelligent de renvoyer 2 chiffres dans ce cas là, avec la possibilité via '%4Y' d'en avoir toujours 4.
Mis à jour par Frédéric Péters il y a plus de 2 ans
c'est converti en datetime(90, 8, 17, ...), ce qui est toujours bon
Pour moi non ça n'est pas bon, le datetime correct ici serait datetime(1990, 8, 17,...).
Mis à jour par Benjamin Dauvergne il y a plus de 2 ans
- Statut changé de Solution proposée à Nouveau
- Assigné à
Benjamin Dauvergnesupprimé
Je ne comprends plus le problème, je laisse.
Mis à jour par Frédéric Péters il y a plus de 2 ans
- Assigné à mis à Frédéric Péters
- Patch proposed changé de Oui à Non
Lors de la saisie dans un <input type="date"> dans un critère sur un tableau de traitement il y a un événement "change" envoyé au fur et à mesure de la saisie et à un moment quand l'agent est encore en cours de frappe ça peut donner cette séquence 10/12/0002, 10/12/0020, 10/12/0202, 10/12/2021.
Mis à jour par Benjamin Dauvergne il y a plus de 2 ans
Ok, mais il y a d'autres moyens d'envoyer la date 0090-08-17 (l'API par exemple) et ça fera la même trace. Ça me semble utile de corriger le code à ce niveau de toute façon (et j'ai vérifié ça le fait avec timetuple aussi ce n'est pas lié à datetime). À vrai dire ma correction n'est pas la plus simple, on pourrait simplement passer l'objet date à psycopg2 qui sait quoi en faire.
Mis à jour par Frédéric Péters il y a plus de 2 ans
- Fichier 0001-backoffice-ignore-filter-dates-with-leading-0-56205.patch 0001-backoffice-ignore-filter-dates-with-leading-0-56205.patch ajouté
- Statut changé de Nouveau à Solution proposée
- Patch proposed changé de Non à Oui
Il y a un moment d'utilisation légitime du navigateur qui produit 0020-05-03 et le patch attaché gère ce moment.
Mis à jour par Benjamin Dauvergne il y a plus de 2 ans
- Statut changé de Solution proposée à Solution validée
Mis à jour par Frédéric Péters il y a plus de 2 ans
- Statut changé de Solution validée à Résolu (à déployer)
commit 70fc9d0c2174cae887017b8630146796391eb909
Author: Frédéric Péters <fpeters@entrouvert.com>
Date: Mon Aug 23 10:14:46 2021 +0200
backoffice: ignore filter dates with leading 0 (#56205)
Mis à jour par Frédéric Péters il y a plus de 2 ans
- Statut changé de Résolu (à déployer) à Solution déployée
backoffice: ignore filter dates with leading 0 (#56205)