Projet

Général

Profil

Bug #37157

last_update_time sur la mauvaise timezone dans les sessions

Ajouté par Emmanuel Cazenave il y a plus de 4 ans. Mis à jour il y a plus de 4 ans.

Statut:
Rejeté
Priorité:
Normal
Assigné à:
-
Version cible:
-
Début:
23 octobre 2019
Echéance:
% réalisé:

0%

Temps estimé:
Patch proposed:
Non
Planning:
Non

Description

Sur #37047, il y au moins ce problème : lorsqu'une session est mise à jour son last_update_time est inscrit en GMT+2 alors que globalement le serveur est en GMT+4.

Genre :

entrouvert@publik-test:~$ date
mercredi 23 octobre 2019, 13:40:50 (UTC+0400)
entrouvert@publik-test:~$ python
Python 2.7.13 (default, Sep 26 2018, 18:42:22) 
[GCC 6.3.0 20170516] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import datetime
>>> datetime.datetime.now()
datetime.datetime(2019, 10, 23, 13, 41, 23, 895877)

Et un moment plus tard d'un print dans wcs/sql.py::Session.store :

{'visiting_objects_keys': ['formdata-omp-inscription-a-la-mediatheque-4'], 'last_update_time': datetime.datetime(2019, 10, 23, 11, 43, 39, 699896), ...

Avec donc le last_update_time en GMT+2 qui est passé à postgres et qui se retrouve tel quel dans la DB.

Il y a quelque chose que je loupe complètement parce que dans Session.store c'est un 'last_update_time': datetime.datetime.now() qui produit ces datetime en GMT+2 mais je ne reproduis pas dans un shell wcs où datetime.datetime.now() sort du GMT+4.

Historique

#2

Mis à jour par Emmanuel Cazenave il y a plus de 4 ans

  • Statut changé de Nouveau à Rejeté

Il y avait TIME_ZONE = 'Europe/Brussels' , avec un TIME_ZONE = 'Indian/Reunion' ça va bien.

Pas compris dans les chemins de code que je suivais à quel moment wcs exploite l'information mais passons.

Formats disponibles : Atom PDF