cas d'utilisation timezone, implémentation SqlAlchemy
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:
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:
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:
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:
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 ?
