Bug #24281
sur les listing de traitement, une date «erronnée» dans les critères provoque un crash
Statut:
Rejeté
Priorité:
Normal
Assigné à:
-
Version cible:
-
Début:
05 juin 2018
Echéance:
% réalisé:
0%
Temps estimé:
Patch proposed:
Non
Planning:
Description
Ce crash étant invisible car le listing est rafraichit en ajax
Exception: type = '<type 'exceptions.ValueError'>', value = 'time data '01/01/18' does not match format '%d/%m/%Y'' Stack trace (most recent call first): File "/usr/lib/python2.7/_strptime.py", line 325, in _strptime 323 if not found: 324 raise ValueError("time data %r does not match format %r" % > 325 (data_string, format)) 326 if len(data_string) != found.end(): 327 raise ValueError("unconverted data remains: %s" % locals: data_string = '01/01/18' format = '%d/%m/%Y' format_regex = <_sre.SRE_Pattern object at 0x8643f30> found = None locale_time = <_strptime.LocaleTime object at 0x7f0f01895bd0> File "/usr/lib/python2.7/_strptime.py", line 467, in _strptime_time 465 466 def _strptime_time(data_string, format="%a %b %d %H:%M:%S %Y"): > 467 return _strptime(data_string, format)[0] ... Form: ... filter-end 'on' filter-end-value '04/06/2018' filter-start 'on' filter-start-value '01/01/18' filter-status 'on'
A noter que « 10/10/18 » n'est pas tout à fait erroné pour un humain.
Demandes liées
Historique
Mis à jour par Frédéric Péters il y a presque 6 ans
- Duplique Bug #15204: Dans le filtre backoffice accepter les dates avec deux chiffres pour l'année ajouté