Produits Entr'ouvert » w.c.s.

Et ailleurs,

'form_option_date_ceremonie': time.struct_time(tm_year=2019, tm_mon=9, tm_mday=28, tm_hour=0, tm_min=0, tm_sec=0, tm_wday=5, tm_yday=271, tm_isdst=-1), 

Je pense que je dois regarder ça et que ça va finir en hotfix :/

Je ne suis pas fan de l'approximation

        if dt.hour == 0 and dt.minute == 0 and dt.second == 0:
            return dt.date()

On peut vraiment pas envoyer quand même un datetime à ce moment ? (parce qu'un cron nocturne qui va modifier un truc à 0h0min0s ça va arriver sur telle ou telle demande, et boum le json aura une date au lieu d'un datetime)

(Bon, en fait, je vois pas la cause de nouveau bogue)

On a uniquement des champs date, pas date/heure, donc on aura toujours 00h00m00, cf les deux exemples ici. Pour les receipt_time, last_update_time, etc. j'ai conservé la gestion explicite qui était en place et prend tout :

                'receipt_time': datetime.datetime(*filled.receipt_time[:6]),
                'last_update_time': datetime.datetime(*filled.last_update_time[:6]),
...
            'time': datetime.datetime(*self.time[:6]) if self.time else None,
            'last_jump_datetime': self.last_jump_datetime

Donc là, je pense l'approximation utilisée assez correcte.

(Bon, en fait, je vois pas la cause de nouveau bogue)

C'est en fait un bug préventif; en Python 3 le time.struct_time est transformé par la sérialisation json en tuple, on se trouve donc dans l'API avec quelque chose comme "creche_var_date_raw": [2020, 1, 15, 16, 17...]; de manière tout à fait silencieuse.

Et comme c'est vu comme un tuple, c'est pris dans le code d'encodage natif json et on n'a même pas la possibilité de changer le comportement.

Donc prévention du bug silencieux qui serait arrivé, j'ai tapé un assert, pour assurer qu'il n'y avait jamais du time.struct_time passant à cet endroit.

(alors oui je suis un boulet j'aurais du taper un notify_of_exception() et laisser l'affaire tourner, histoire de ne pas crasher)