Projet

Général

Profil

Development #60383

toulouse_smart: passer les dates en UTC à smart

Ajouté par Nicolas Roche il y a plus de 2 ans. Mis à jour il y a plus de 2 ans.

Statut:
Fermé
Priorité:
Normal
Assigné à:
Nicolas Roche
Version cible:
-
Début:
06 janvier 2022
Echéance:
% réalisé:

0%

Temps estimé:
Patch proposed:
Oui
Planning:
Non

Description

J'ai l'impression que wcs fournit des dates sur le fuseau horaire français.
ex: 2021-01-30T18:00:00

Cela reste à préciser (#60337) mais smart semble traiter des dates UTC.
ex: 2021-01-30T17:00:00Z

Les dates ne sont pas stockée dans le connecteur, juste transférées.
Ainsi suivant l'interlocuteur, il faudrait faire la conversion :
  • 'Europe/Paris' -> UTC pour smart
  • UTC -> 'Europe/Paris' pour w.c.s

Fichiers

0001-toulouse_smart-manage-timezone-translations-60383.patch (12,4 ko) 0001-toulouse_smart-manage-timezone-translations-60383.patch Nicolas Roche, 07 janvier 2022 12:12
0001-toulouse_smart-manage-timezone-translations-60383.patch (12,2 ko) 0001-toulouse_smart-manage-timezone-translations-60383.patch Nicolas Roche, 07 janvier 2022 15:42
0001-toulouse_smart-manage-timezone-translations-60383.patch (12,2 ko) 0001-toulouse_smart-manage-timezone-translations-60383.patch Nicolas Roche, 12 janvier 2022 17:17

Révisions associées

Révision fd86f95f (diff)
Ajouté par Nicolas Roche il y a plus de 2 ans

toulouse_smart: manage timezone translations (#60383)

Historique

#1

Mis à jour par Thomas Noël il y a plus de 2 ans

J'ai l'impression que wcs fournit des dates sur le fuseau horaire français.

A quel moment ? Si c'est dans un appel webservice, w.c.s. il fournit ce qu'on lui demande...

Pour info, {{ une_date|date:"c" }} sort de l'ISO 8601.

Si tu veux jouer avec les fuseaux, regarde https://docs.djangoproject.com/fr/2.2/topics/i18n/timezones/#time-zones-in-templates

{% load tz %}{{ une_date|utc }} te renvoie un objet datetime en UTC, à partir de ça tu peux forger une chaine « 2021-01-30T17:00:00Z »

#2

Mis à jour par Benjamin Dauvergne il y a plus de 2 ans

Moui, moi je ne ferai rien dans w.c.s si c'est inutile. w.c.s. envoie du localtime par défaut, on parse le localtime et on ressort en UTC avec le suffixe Z puisque SMART semble avoir un parseur compatible RFC3339 au minimum.

#3

Mis à jour par Benjamin Dauvergne il y a plus de 2 ans

Benjamin Dauvergne a écrit :

Moui, moi je ne ferai rien dans w.c.s si c'est inutile. w.c.s. envoie du localtime par défaut, on parse le localtime et on ressort en UTC avec le suffixe Z puisque SMART semble avoir un parseur compatible RFC3339 au minimum.

Dans la proposition autant je vois bien dans le code où on envoie des dates à SMART mais par contre je ne vois pas la liste des cas où SMART nous retourne une date.

#4

Mis à jour par Nicolas Roche il y a plus de 2 ans

Smart nous renvoie les dates passées ( interventionCreated et interventionDesired ) modifiées (ou pas).
Seule interventionCreated est mise à jour.
Par exemple via le endpoint get_intervention ou sur la réponse à v1/intervention (endpoint create_intervention ).

#5

Mis à jour par Benjamin Dauvergne il y a plus de 2 ans

Nicolas Roche a écrit :

Smart nous renvoie les dates passées ( interventionCreated et interventionDesired ) modifiées (ou pas).
Seule interventionCreated est mise à jour.
Par exemple via le endpoint get_intervention ou sur la réponse à v1/intervention (endpoint create_intervention ).

Ok donc on a juste à traiter ces deux champs en entrée et en sortie.

#6

Mis à jour par Nicolas Roche il y a plus de 2 ans

Seule interventionCreated est mise à jour.

En fait non, les 2 dates sont modifiées par Smart, mais différemment.

J'envoie :

(Pdb) self.payload
{ ...
'interventionCreated': '2022-01-07T10:40:19.000000Z',
'interventionDesired': '2022-01-07T10:40:19.000000Z'
}

et je reçois :
(Pdb) self.result
'interventionCreated': '2022-01-07T10:41:44.657Z',
'interventionDesired': '2022-01-07T10:40:19Z'

Peut-être attendre un retour sur #60337 avent de relire/pousser ce patch ?

il faudrait nous préciser le format attendu en entrée et renvoyé par SMART.

#7

Mis à jour par Benjamin Dauvergne il y a plus de 2 ans

Nicolas Roche a écrit :

Peut-être attendre un retour sur #60337 avent de relire/pousser ce patch ?

il faudrait nous préciser le format attendu en entrée et renvoyé par SMART.

Je ne sais pas, pour moi le bug était évident avant sans le ticket de Cyril, ajouter un 'Z' à une date locale formatée ISO n'en a jamais fait une date UTC correcte (pour pas dire que c'était mal et que ça a passé ma relecture :) ).

#8

Mis à jour par Benjamin Dauvergne il y a plus de 2 ans

  • Statut changé de Solution proposée à En cours
Faut arrêter de réinventer la roue, utilise django.utils.dateparse.parse_datetime pour parser tes dates (ou dateutil.parser.isoparse) pas strptime
  • dans le sens w.c.s. -> SMART : make_aware(parse_datetime(value)).as_timezone(django.utils.timezone.utc).isoformat() + 'Z'
  • dans le sens SMART -> w.c.s : localtime(parse_datetime(value)).isoformat()
#9

Mis à jour par Nicolas Roche il y a plus de 2 ans

Zut, smart n'accepte pas l'isoformat "aware" en entrée.

'2021-06-30T16:08:05+00:00Z
                    ^^^^^^

J'ai repris tes indications (merci pour le parseur), cependant :
  • j'ai utilisé strftime pour pousser vers smart (je n'ai pas réussi à avoir une date naïve sur le fuseau UTC)
  • j'ai poussé une date naïve vers w.c.s.

Dans l'inspecteur je récupère bien la date de ma demande :

form_workflow_data_smart_response_data_payload_interventionCreated 2022-01-07T14:22:30.000000Z
form_workflow_data_smart_response_data_payload_interventionDesired 2022-01-07T14:22:30.000000Z

form_workflow_data_smart_response_data_result_interventionCreated  2022-01-07T15:22:32.891000
form_workflow_data_smart_response_data_result_interventionDesired  2022-01-07T15:22:30

et wcs semble content :

{{ form_workflow_data_smart_response_data_result_interventionCreated|date:"Y/m/d H:i:s"}}
2022/01/07 15:22:32

#11

Mis à jour par Benjamin Dauvergne il y a plus de 2 ans

Ok parce que c'est faux "'2021-06-30T16:08:05+00:00Z" n'est pas valide y a deux fuseaux horaires "+00:00" et "Z", soit tu fais aware_datetime_in_utc.isoformat().replace('+00:00', 'Z') soit tu fais aware_date_in_utc.replace(tzinfo=None).isoformat() + 'Z'

#12

Mis à jour par Benjamin Dauvergne il y a plus de 2 ans

  • Statut changé de Solution proposée à En cours
#13

Mis à jour par Nicolas Roche il y a plus de 2 ans

n'est pas valide y a deux fuseaux horaires

Désolé, décidément j'ai du mal.

dans le sens w.c.s. -> SMART : make_aware(parse_datetime(value)).as_timezone(django.utils.timezone.utc).isoformat() ...

J'ai donc repris ça.

#14

Mis à jour par Benjamin Dauvergne il y a plus de 2 ans

  • Statut changé de Solution proposée à Solution validée

Nicolas Roche a écrit :

n'est pas valide y a deux fuseaux horaires

Désolé, décidément j'ai du mal.

dans le sens w.c.s. -> SMART : make_aware(parse_datetime(value)).as_timezone(django.utils.timezone.utc).isoformat() ...

J'ai donc repris ça.

Si tu peux confirmer que SMART comprend bien le "+00:00", c'est bon pour moi.

#15

Mis à jour par Nicolas Roche il y a plus de 2 ans

Si tu peux confirmer que SMART comprend bien le "+00:00", c'est bon pour moi.

D'après mes tests oui (mais j'avoue que ça reste empirique).

#16

Mis à jour par Nicolas Roche il y a plus de 2 ans

  • Statut changé de Solution validée à Résolu (à déployer)
commit fd86f95ff02c565651d48a7f92bcd6d36b3ae2fd
Author: Nicolas ROCHE <nroche@entrouvert.com>
Date:   Fri Jan 7 09:03:04 2022 +0100

    toulouse_smart: manage timezone translations (#60383)
#17

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
#18

Mis à jour par Transition automatique il y a environ 2 ans

Automatic expiration

Formats disponibles : Atom PDF