Django: problème de fuseau horaire
NOTE: j'ai supprimé la question telle qu'elle existait auparavant, et de fournir uniquement les informations pertinentes ici.
Notre serveur de base de données (RH) a TIME_ZONE = "Europe/London" spécifié. Et, au sein de l'Django settings.py nous spécifier TIME_ZONE = "America/New_York".
Et, dans ma classe de Modèle, j'ai précisé:
created = models.DateTimeField(editable=False,auto_now=False, auto_now_add=True)
modified = models.DateTimeField(editable=False,auto_now=True, auto_now_add=True)
Quand je puis aller chercher les données dans l'admin du site, je reçois UTC/GMT au lieu de l'est.
Je pensais que tout ce que l'heure est réglée automatiquement par Django depuis que j'ai précisé "America/New_York" comme Django fuseau Horaire.
Toute aide/clarification est apprécié.
Merci
Eric
source d'informationauteur
Vous devez vous connecter pour publier un commentaire.
En s'appuyant sur la date/time "automagique" est dangereux et ces auto_add les paramètres du modèle sont un piège. Toujours comprendre le fuseau horaire(s) qui vous intéresse. Python rend cela plus facile de fixer une tzinfo membre de sa datetime objets. Bien que ces objets sont "naïve" par défaut, je vous encourage à toujours attacher tzinfo détail. Encore Python besoin d'une aide supplémentaire soit avec python-dateutil ou pytz (ce que j'utilise). Voici une règle universelle, mais - toujours stocker vos datetimes dans une base de données que l'UTC.
Pourquoi? Vos utilisateurs peuvent être dans différents locaux, les téléphones mobiles et les ordinateurs portables de voyage, les serveurs sont mal configurés ou en miroir dans différents fuseaux horaires. Donc, beaucoup de maux de tête. Datetimes ne doit jamais être naïf et si ils sont (dans une base de données) et vous devez le contexte, également inclure un champ timezone dans le tableau.
Donc dans votre cas.
Si vous utilisez pytz, le localiser() méthode est grand. Python objet datetime a l'utile replace() et astimezone().
Une note plus, si votre base de données de fuseau horaire naïf (comme MySQL) assurez-vous que votre datetimes sont en UTC, puis utiliser le remplacer(tzinfo=None) parce que le connecteur de base de données ne peut pas gérer tz-connaissance des objets.
Ici est un fil avec des détails sur Django auto_now champs.
Tout d'abord, je veux stocker mes données que l'UTC cause de son un bon point de départ.
Alors permettez-moi de demander, Pourquoi avez-vous besoin à la fois dans l'est, est-ce pour l'utilisateur final, ou avez-vous besoin de faire de la logique sur le serveur et le besoin qu'il en EST?
Si ses pour l'utilisateur final, une solution facile est de laisser les utilisateurs du navigateur de gérer la conversion de l'heure correcte. Sur le serveur de convertir l'objet datetime pour un timestamp:
Puis sur la page web instancier un objet Date:
Maintenant, sur l'autre main, si vous voulez avoir le temps dans la bonne zone sur le serveur de sorte que vous pouvez exécuter la logique. Je recommande l'utilisation de l'aide de python-dateutil. Il vous permettra de vous déplacer facilement à un autre fuseau horaire:
Maintenant si tu veux vraiment le magasin de type datetime dans l'est, vous avez besoin de changer l'heure sur le serveur de base de données (comme Ajay Yadav et gorus dit). Je ne sais pas pourquoi vous voulez les stocker en tant que EST, mais là encore je ne sais pas ce que votre demande est.
Quand vous dites auto_now_add=True, la valeur sera ajoutée par votre serveur de base de données et non pas votre django serveur. Donc, vous devez définir le fuseau horaire de votre serveur de base de données.
Depuis que vous l'avez édité la question, je vais modifier ma réponse 🙂 Django ne peut pas contrôler le fuseau horaire de votre base de données, de sorte que le moyen de résoudre ce problème est de mettre à jour le fuseau horaire de votre db. Pour MySql, exécutez cette requête:
SELECT @@global.time_zone, @@session.time_zone;
Il doit retourner
SYSTEM, SYSTEM
par défaut, ce qui, dans votre cas, signifie "Europe/London", et la cause de votre problème. Maintenant que vous avez vérifié cela, suivez les instructions dans le premier commentaire sur cette page:http://dev.mysql.com/doc/refman/5.5/en/time-zone-support.html
N'oubliez pas de redémarrer le serveur MySql après avoir mis à jour le fuseau horaire pour que les modifications prennent effet.