Discussion :

[flapili]

bonjour,

Bon pour le coup la question n'est pas uniquement "Python", en faite il s'agit de plein de petites questions qui tournent autours des notions de timezones/UTC.


now.datetime.datetime.now() retourne la date courante "naïve" du système jusque là ça va (naïve dans le sens où c'est une date absolue, sans notion de timezone). Le problème étant qu'une date absolue est considéré comme UTC, c'est à dire tz=0.

datetime.astimezone(tz=None) semble retourner le datetime tel quel en y associant le timezone passé en argument, mais dans le cas où aucun timezone n'est passé il retourne le timezone système.
Du coup

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
>>> now.astimezone().astimezone()
datetime.datetime(2020, 5, 11, 7, 8, 43, 538788, tzinfo=datetime.timezone(datetime.timedelta(seconds=7200), 'Paris, Madrid (heure d’été)'))

semble tout à fait correspondre à mon besoin, cependant sur beaucoup de ressource en ligne ça se base sur pyzt /dateutils /arrow ou bien des différences assez peu élégantes

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
>>> now = datetime.datetime.now()
>>> now - datetime.datetime.utcfromtimestamp(now.timestamp())
datetime.timedelta(seconds=7200)

D'après la documentation ce comportement de astimezone est "relativement" nouveau "Changed in version 3.6: The astimezone() method can now be called on naive instances that are presumed to represent system local time." du coup ça ne semble pas être un détournement de fonction qui fait pas ça marche presque par effet de bord.

Est ce selon vous la bonne méthode ? (un NotImplementedError ou autre doit être levé dans ce cas ?)
à priori peut de risque à moins de changer de timezone en cours de route et d'avoir une race condition, mais faut le vouloir franchement ...


Maintenant c'est sur l'utilisation (et c'est là que ça va déborder du cadre de Python) que j'ai quelques questions, est ce qu'il serait préférable de toujours stocker en base de donnée la date locale et le timezone associé plutôt qu'en UTC/timestamp ? même dans le cas d'une colonne created_at, qu'en est t'il pour une colonne updated_at ?

ET là c'est encore un autre point puisque je vais aborder les bases de données, par exemple dans le cas d'un changement d'heure est ce que stocker uniquement en UTC ne posera pas un décalage d'une heure entre heure d'été et d'hivers ? est ce qu'il y a une normalisation pour appliquer le bon timezone en fonction de la date ou bien pas du tout.


Histoire de repartir coté implémentation Python je souhaiterais utiliser Gino donc avec une base postgresql, (Gino se base sur SqlAlchemy) il me suffirait d'avoir ça dans mon schéma pour une date

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
class User(db.Model):
	__tablename__ = "users"
 
	id = db.Column(db.Integer(), primary_key=True)
	date_au_pif = db.Column(db.DateTime(timezone=True))
	created_at = db.Column(db.DateTime(timezone=True), server_default=saqlalchemy.sql.func.now())
	updated_at = db.Column(db.DateTime(timezone=True), ?)

Cependant j'ai quelques doutes pour created_at et updated_at, j'ai compris que sqlalchemy.sql.functions.now faisait référence à la fonction SQL now, j'ai également vu qu'il existait default et server_default, ce dernier laisserais entièrement le boulot à la base This construct does not specify any DDL and the implementation is left to the database, donc dans mon cas il serait préférable de l'utiliser ? le 1er quand à lui n'a de sens que si la valeur n'est calculable que par Python, je suis bon ?

ps: db.DateTime n'est qu'un alias

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
>>> gino.Gino().DateTime
<class 'sqlalchemy.sql.sqltypes.DateTime'>

par contre pour le on_update je suis moins sur de comprendre: server_onupdate"representing a database-side default generation function, such as a trigger. This indicates to SQLAlchemy that a newly generated value will be available after updates. This construct does not actually implement any kind of generation function within the database, which instead must be specified separately.", pas sur que ce me soit très utile.
et le onupdate doit être "A scalar, Python callable, or ClauseElement" me met totalement dans le doute, est ce que ça veux dire que la mise à jour de la valeur est faite par SqlAlchemy et non par la base de donnée directement ?

[danielhagnoul]

Je travaille exclusivement les dates au format ISO long depuis longtemps. On prend ainsi automatiquement en compte le fuseau horaire et le changement d'heure, et l'on peut convertir une date d'un endroit dans un autre sans problème. Voir : Python, datetime, dateutil. Manipulation de dates au format ISO long.

[wiztricks]

Salut,

Le temps sert à construire une chronologie (un compteur monotone croissant).
Si utilisateur, application et serveur de la base de données sont sur le même PC/serveur utiliser le temps local ou le temps UTC fonctionnera tant qu'on s'assure que la machine redémarre avec la date/heure correcte.

Ça commence à se compliquer lorsque le serveur de base de données est accessible via plusieurs applications/clients distincts.

S'ils sont suffisamment proches pour être dans le même "timezone", pas facile de contrôler qu'ils sont tous à la même/bonne date/heure et on va préférer utiliser un horodatage généré par le serveur de la base de données.

L'horodatage UTC devient incontournable lorsqu'on à des clients Web qui peuvent accéder aux services en 24/24 depuis l'ensemble de la planète.
Mais il y a ce qu'on stocke dans la base de donnée (UTC) et des conversions à faire lorsqu'un utilisateur saisie une date "locale" (avec éventuellement des spécificités en fonction du SGDB).

Tout çà pour dire que les outils sont là (comme les outils de traduction de texte), les mettre en œuvre complique un peu le code mais n'est pas indispensable pour toute application.

- W

[flapili]

Merci de vos réponses,



En faite toutes mes interrogations tournent autour des changements d'heures plus que des timezone, ces derniers étant plus des solutions à vrai dire.

Par exemple dans le cas d'une date de création d'un post de forum à 12h heure locale en France métropolitaine en heure d'hivers on obtient 10h en UTC, mais en heure d'été je verrais que le post a été créé à 11h.

De même comment préserver la cohérence des durées écoulés entre la création de deux objets ?

Est t'il possible si l'on stock des UTC d'être capable de retrouver le 12h à partir du temps UTC + de la date, existe il déjà des outils qui permet de faire ça ?


Quand bien même je me demande si ça à de l'importance, dans le sens où lorsque l'on veux des heures fixes (démarrage d'un pc à une heure précise, tache de sauvegarde, ect) on est déjà fixé à un timezone particulier.



Personne n'as jamais utilisé SQLAlchemy ici ?

[wiztricks]

Salut,

Par exemple dans le cas d'une date de création d'un post de forum à 12h heure locale en France métropolitaine en heure d'hivers on obtient 10h en UTC, mais en heure d'été je verrais que le post a été créé à 11h.

A priori, le module externe pytz sait gérer çà (mais je n'ai pas testé) pour autant que sa base de donnée soit à jour.

Personne n'as jamais utilisé SQLAlchemy ici ?

Je ne vois pas trop le rapport.

- W

[flapili]

Je ne vois pas trop le rapport.

Une partie de mes questions concernent SqlAlchemy sur la gestion des updates et valeurs par défaut,

J'ai finalement trouvé des réponses qui semblent satisfaisantes:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
class Table(db.Model):
	__tablename__ = "table"
 
	created_at = db.Column(db.DateTime(timezone=True), server_default=saqlalchemy.sql.func.now())
	updated_at = db.Column(db.DateTime(timezone=True), server_default=text('CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP'))

, mais je n'ai pas encore pu tester

[flapili]

bon finalement j'ai compris pas mal de chose avec la doc de Django (alors que je ne l'utilise même pas), si certains tombent sur se sujet après s'être posé la même question faites y un tour