Remarque: j'ai supprimé la question tel qu'il existait précédemment et fournissant uniquement les informations pertinentes ici.
Notre serveur de base de données (RH) aime_zone = "Europe / London" spécifié. Et, dans le Django Params.py, nous spécifions TIME_ZONE = "AMERIQUE / NEW_YORK". P>
et, dans ma classe de modèle, j'ai spécifié: p>
created = models.DateTimeField(editable=False,auto_now=False, auto_now_add=True) modified = models.DateTimeField(editable=False,auto_now=True, auto_now_add=True)
5 Réponses :
Depuis que vous avez édité la question, je modifierai ma réponse :) Django ne peut pas contrôler le fuseau horaire de votre dB, de sorte que la manière de résoudre ce problème consiste à mettre à jour le fuseau horaire de votre DB. Pour MySQL, exécutez cette requête:
Ceci devrait renvoyer http://dev.mysql.com/ DOC / REFMAN / 5.5 / FR / TIME-ZONE-SUPPORT.HTML
N'oubliez pas de redémarrer MySQL Server après avoir mis à jour le fuseau horaire des modifications à prendre effet. SELECT @@ global.time_zone, @@ session.time_zone;
système, système par défaut, qui signifie "Europe / London" et la cause de votre problème. Maintenant que vous avez vérifié cela, suivez les instructions du premier commentaire de cette page:
Tant que DB Magasins de décalage du fuseau horaire (ne sait pas sur MySQL, mais Postgres le fait avec le type de données "horodatage avec le fuseau horaire"), Django ne devrait pas se soucier des paramètres de DB - il devrait simplement faire les mathématiques. Même si Django est considéré comme équitable db-agnostique, de préférence, Eric devrait spécifier quel serveur DB il fonctionne (nom et version) - cela aiderait à déboguer.
Lorsque vous dites AUTO_NOW_ADD = true, la valeur sera ajoutée par votre serveur de base de données et non votre serveur Django. Vous devez donc définir un fuseau horaire sur votre serveur de base de données.
Tout d'abord, je voudrais stocker mes données car l'UTC entraîne son bon point de départ.
Alors permettez-moi de poser cela, pourquoi avez-vous besoin du temps dans l'est, est-ce pour l'utilisateur final, ou devez-vous faire la logique sur le serveur et en avoir besoin dans l'est? P>
si C'est pour l'endutilisateur, une solution facile consiste à laisser le navigateur des utilisateurs à convertir à la bonne heure. Sur le serveur convertir l'objet DateTime en horodatage: p> puis sur la page Web instanive d'un objet de date: p> from datetime import datetime
from dateutil import zoneinfo
from_zone = zoneinfo.gettz('UTC')
to_zone = zoneinfo.gettz('America/New_York')
utc = created # your datetime object from the db
# Tell the datetime object that it's in UTC time zone since
# datetime objects are 'naive' by default
utc = utc.replace(tzinfo=from_zone)
# Convert time zone
eastern_time = utc.aztimezone(to_zone)
Todd, je suppose que ma question n'était pas complète. Mais je vois tes points et ils sont bons. Je vais utiliser certains de vos exemples dans mon projet actuel. Merci!
S'appuyant sur la date / l'heure 'Automagic' est dangereux et ces paramètres de modèle AUTO_ADD sont un piège. Toujours comprendre le ou les fuseaux fusionnés que vous avez affaire. Python facilite cette tâche en attachant un membre TzInfo à ses objets DateTime. Bien que ces objets soient «naïfs» par défaut, je vous encourage à toujours attacher les détails TzInfo. Toujours Python a besoin d'une aide supplémentaire avec python-datetutil ou pytz (ce que j'utilise). Voici une règle universelle, cependant, stockez toujours vos DateTimes dans une base de données comme UTC.
pourquoi? Vos utilisateurs peuvent être dans différents locaux, téléphones mobiles et voyages ordinateurs portables, les serveurs sont mal configurés ou mirés dans différentes fuseaux horaires. Tant de maux de tête. Les datetés ne doivent jamais être naïves et s'ils sont (comme dans une base de données) et vous avez besoin du contexte, incluez également un champ de fuseau horaire dans la table.
Donc dans votre cas.
Si vous utilisez Pytz, le localiser () la méthode est géniale. L'objet DateTime de Python a le remplacement utile () et asthonezone ().
Une note de plus, si votre base de données est la TimeZone naïf (comme MySQL), assurez-vous que vos DateTimes sont en UTC, puis utilisez remplacer (tzinfo = aucun) car le connecteur de base de données ne peut pas gérer les objets Cachets TZ.
Voici un thread avec détail sur les champs Auto_Now de Django.
La solution la plus simple / la plus rapide [Dite ci-dessus par Ajay Yadav] est-ce,
Add attribut Time_Zone à la section de la base de données dans Paramètres.py,
Paramètres.py pour les choix de fuseau horaire disponibles , voir la documentation officielle
Merci. Cela m'a vraiment aidé beaucoup. Voici la documentation de ce paramètre: docs.djangoproject.com/fr /3.2/Ref/Settings/#time-zone
Qu'est-ce que vous en obtenez de cela? >>> Importer DateTime >>> DateTime.DateTime.now ()
Je viens de mettre à jour les informations du serveur. Le fuseau horaire est réglé sur Server Europe / London.
Je préfère ne pas utiliser auto_now. Il délégué au serveur de base de données, qui devrait avoir un fuseau horaire. De cette façon, vous perdez la flexibilité nécessaire pour avoir différentes zones de temps par l'utilisateur.