Django Timezone Confusion; Postgres et Apache

Question

Configuration: Plusieurs sites sur Django sur le même ensemble de serveurs, étant servis par le même groupe de processus Apache. Certains sites sont TZ Est; certains sont centraux. La base de données est PSQL fonctionnant sur un serveur séparé. Quand j'ai commencé, je n'ai pas beaucoup réfléchi à la façon dont les différents sites géreraient les fuseaux horaires; Je suppose que j'ai vu le réglage de TIMEZONE dans Django et je me suis dit que ça allait le gérer. Maintenant, je vois les fissures.

Premier problème: Le fuseau horaire semble osciller entre Eastern et Central. Ma compréhension de cela à partir de la recherche sur ce site est que c'est parce que l'environnement var est réglé sur le processus Apache en fonction du site Django pour lequel il traite une requête, et si ce processus traite une requête sur un autre site TZ, le fuseau horaire est faux. Je crois que la solution que j'ai trouvée ici était que les sites de différents fuseaux horaires doivent avoir différents groupes de processus les servant. S'il vous plaît corriger si mal.

Deuxième problème: Localement sous Linux, j'ai exécuté un ./manage.py runserver à partir de l'un de mes sites avec l'heure centrale (je suis dans l'Est). J'ai créé un actif, dont la date de publication s'affichait correctement en une heure dans l'admin. En regardant l'entrée PostgresSQL réelle, le fuseau horaire de la date de publication est toujours répertorié comme -04. Est-ce que Postgres utilise simplement le fuseau horaire du serveur/ordinateur lui-même et ignore tout paramètre TZ dans Django? Ainsi, toutes les entrées enregistrées sur un serveur Postgres à l'heure de l'Est afficheraient -04 ou -05 en fonction de l'heure d'été?

Si quelqu'un d'autre a traité quelque chose comme ceci, des conseils sont appréciés. Même si je divise les processus Apache pour les sites centraux de sorte que leurs paramètres TZ ne se croisent pas, j'ai toujours le problème Postgres à traiter. Et puis je suis curieux; si l'horodatage PSQL est Central et que le paramètre TZ est Eastern, par exemple, les champs datetime prennent-ils en compte TZ? Par exemple, si vous utilisez datetime.datetime.now() lorsque Django est défini sur EST, et qu'il est renvoyé à 14h00, le contenu du filtre est moins élevé que le résultat de la publication. Vous recherchez du contenu dont l'heure de publication était 13h00 HNC ou plus tôt?

Answer 1

Voici quelques détails sur le fuseau horaire de manipulation dans Django et Postgres, mais je fortement recommandent traiter exclusivement UTC sur le backend et seulement la conversion à une zone heure locale dans le frontend lors de la présentation d'un horodatage UTC à un utilisateur. En Python, vous pouvez obtenir l'heure actuelle en UTC via datetime.datetime.utcnow(). J'ai même mis mes serveurs dans le fuseau horaire UTC, mais ce n'est pas strictement nécessaire.

fuseaux horaires multiples ne fonctionnent pas bien dans Django; voir this ticket. Les objets datetime dans la bibliothèque standard Python sont naïfs, et vous avez besoin d'une librairie comme pytz pour résoudre ce problème, mais autant que je sache, Django renvoie toujours des objets datetime naïfs, pas ceux que vous pouvez construire avec pytz.

Postgres vérifiera plusieurs endroits pour déterminer le fuseau horaire, y compris la variable d'environnement TZ, mais TZ devra être dans l'environnement du processus postgres:

PostgreSQL 8.5.3. Fuseau horaire

Si fuseau horaire n'est pas spécifié dans postgresql.conf ni comme un commutateur de ligne de commande maître de poste , le serveur tentatives d'utiliser la valeur de la variable d'environnement TZ comme le fuseau horaire par défaut .Si TZ est pas défini ou est aucun des noms de fuseaux horaires connus à PostgreSQL, le serveur tente de déterminer le temps par défaut du système d'exploitation la zone en vérifiant le comportement de la fonction de la bibliothèque C localtime(). Le fuseau horaire par défaut est sélectionné comme correspondance la plus proche parmi les fuseaux horaires connus de PostgreSQL .