common: Fix client time parser

[amine-bentayeb-coopengo]

Fix #PCLAS-282

[PierreCookie]

Concrètement, c'est quelle valeur qu'il n'arrive pas à parser ?

[amine-bentayeb-coopengo]

quand la fonction reçoit un time (ex: 10:20:50) il passe dans la condition if len(text) == 8 and dayfirst: et elle essaie de le formater avec datetime.datetime.strptime(text, '%d%m%Y') .. ce qui renvoie une ValueError

[PierreCookie]

Le bug serait pas plutôt l'appel à la fonction date_parse alors qu'on a un time ?

[nicoe]

Le bug serait pas plutôt l'appel à la fonction date_parse alors qu'on a un time ?

Le code sur lequel Amine ajoute le try except, c'est du code qu'on a ajouté car la lib derrière ne parse pas les dates qu'on donne dans un format 'DDMMYYYY' mais naïvement je n'avais pas remarqué que 'HH:MM:SS' ça a aussi une longueur de 8.

Par contre je n'ai pas encore eu le temps de regarder pourquoi ça marche chez moi mais pas chez vos clients (ma première hypothèse c'est que je testais avec l'utilisateur admin en anglais).

[JCavallo]

A priori ne résoud pas tous les cas identifiés dans le ticket

The merge-base changed after approval.

[nicoe]

Je pense qu'il faut remplacer le test par celui-ci (ne pas oublier d'importer re):

    if re.match(r"\d{8}", text):
        return datetime.datetime.strptime(text, '%d%m%Y')
    elif re.match(r"\d{6}", text):
        return datetime.datetime.strptime(text, '%d%m%y')

Ainsi seul les chaines qui matchent le format seront parsées par strptime sinon on fallback sur la lib.

Je n'ai pas réussi à reproduire le problème qui se pose avec uniquement la date (dans la fiche le cas sur le wizard "Démarrer la souscription" et ce même en français, je me demande s'il n'y a pas eu un changement dans le format des dates pour ce client spécifiquement mais je ne l'ai pas vu dans la DB).

[nicoe]

Finalement on a revu toute la fonction: #42

[JCavallo]

Closed in favor of #42