J'ai fait la configuration du serveur plusieurs fois avec les mêmes paramètres, mais cette fois, je vois le message d'erreur. Il ne permet même pas de migrer la base de données.
LANGUAGE_CODE = 'en-us' TIME_ZONE = 'UTC' USE_I18N = True USE_L10N = True USE_TZ = True
Voici mes paramètres.py pour le fuseau horaire.
System check identified no issues (0 silenced).
Exception in thread django-main-thread:
Traceback (most recent call last):
File "/usr/lib/python3.9/threading.py", line 954, in _bootstrap_inner
self.run()
File "/usr/lib/python3.9/threading.py", line 892, in run
self._target(*self._args, **self._kwargs)
File "/home/datanal/datanal-samply/venv/lib/python3.9/site-packages/django/utils/autoreload.py", line 53, in wrapper
fn(*args, **kwargs)
File "/home/datanal/datanal-samply/venv/lib/python3.9/site-packages/django/core/management/commands/runserver.py", line 120, in inner_run
self.check_migrations()
File "/home/datanal/datanal-samply/venv/lib/python3.9/site-packages/django/core/management/base.py", line 458, in check_migrations
executor = MigrationExecutor(connections[DEFAULT_DB_ALIAS])
File "/home/datanal/datanal-samply/venv/lib/python3.9/site-packages/django/db/migrations/executor.py", line 18, in __init__
self.loader = MigrationLoader(self.connection)
File "/home/datanal/datanal-samply/venv/lib/python3.9/site-packages/django/db/migrations/loader.py", line 49, in __init__
self.build_graph()
File "/home/datanal/datanal-samply/venv/lib/python3.9/site-packages/django/db/migrations/loader.py", line 212, in build_graph
self.applied_migrations = recorder.applied_migrations()
File "/home/datanal/datanal-samply/venv/lib/python3.9/site-packages/django/db/migrations/recorder.py", line 77, in applied_migrations
return {(migration.app, migration.name): migration for migration in self.migration_qs}
File "/home/datanal/datanal-samply/venv/lib/python3.9/site-packages/django/db/models/query.py", line 276, in __iter__
self._fetch_all()
File "/home/datanal/datanal-samply/venv/lib/python3.9/site-packages/django/db/models/query.py", line 1261, in _fetch_all
self._result_cache = list(self._iterable_class(self))
File "/home/datanal/datanal-samply/venv/lib/python3.9/site-packages/django/db/models/query.py", line 57, in __iter__
results = compiler.execute_sql(chunked_fetch=self.chunked_fetch, chunk_size=self.chunk_size)
File "/home/datanal/datanal-samply/venv/lib/python3.9/site-packages/django/db/models/sql/compiler.py", line 1170, in execute_sql
return list(result)
File "/home/datanal/datanal-samply/venv/lib/python3.9/site-packages/django/db/models/sql/compiler.py", line 1569, in cursor_iter
for rows in iter((lambda: cursor.fetchmany(itersize)), sentinel):
File "/home/datanal/datanal-samply/venv/lib/python3.9/site-packages/django/db/models/sql/compiler.py", line 1569, in <lambda>
for rows in iter((lambda: cursor.fetchmany(itersize)), sentinel):
File "/home/datanal/datanal-samply/venv/lib/python3.9/site-packages/django/db/utils.py", line 97, in inner
return func(*args, **kwargs)
File "/home/datanal/datanal-samply/venv/lib/python3.9/site-packages/django/db/backends/postgresql/utils.py", line 6, in utc_tzinfo_factory
raise AssertionError("database connection isn't set to UTC")
AssertionError: database connection isn't set to UTC
OS: Ubuntu 21.04 Version Python: 3.9.5 Django Version: 3.0 PostgreSQL: 13.3
J'ai également parcouru une autre question mais n'a trouvé aucune solution. Y a-t-il quelqu'un qui peut m'aider à faire cela? J'ai une configuration de serveur multiple avec le même code sans rien changer et j'ai fonctionné, mais ce n'est pas le cas.
5 Réponses :
Une mise à jour récente de PSYCOPG2 La version 2.9 provoque ce problème comme expliqué dans ce numéro GitHub:
https://github.com/psycopg/psycopg2/issues/1293#issuecomment-862835147
PSYCOPG 2.9 a modifié la valeur transmise en tzinfo_factory d'un int à un timedElta. Django 2.2 (peut-être plus récent mais je suis sur 2.2) a un chèque pour offset == 0 et puisque TimeDelta (0)! = 0 Il devient boom.
Une solution actuelle consisterait à rétrograder psycopg2 (ou psycopg2-binaire si vous utilisez le package autonome) en dessous de 2.9 (par exemple psycopg2> = 2.8, ) Dans votre fichier d'exigences.
Par exemple, vous pouvez rétrograder à 2.8.6 en utilisant:
pip install psycopg2-binary==2.8.6
ou
pip install psycopg2==2.8.6
Si vous utilisez la poésie, vous pouvez faire poésie ajouter psycopg2@2.8.6 pour corriger Votre version à 2.8.6 .
psycopg2 Release History
Peut confirmer cela. Le problème est apparu après la mise à niveau psycopg2-binaire de 2.8.6 à 2.9. Le faire le résoudre le résout
Oui, je viens de recevoir le même problème, rétrogradant PSYCOPG2 à 2.8.6 l'a résolu.
L'installation actuelle de la révision échoue pour ce même problème.
Cela me résout aussi le même problème
Je peux confirmer que la solution ci-dessus de rétrogradation pour installer PSYCOPG2-binaire == 2.8.6 fonctionne, je pense que Psycopg2-binary-2.9.1 a des problèmes qui doivent être résolus
Cela a également résolu mon problème devrait être accepté comme réponse si cela fonctionne pour l'OP.
J'ai également résolu le problème pour moi.
C'est la bonne réponse à partir de maintenant pour moi.
Cela me résout le même problème. Merci
PSYCOPG 2.8.6 fonctionne maintenant très bien avec Django 3.0.1
Heads up: following the linked question in the first comment I eventually ended up on the matching psycopg2 issue about the Problème qui est fermé . Ce que les gars psycopg2 avaient à dire, c'est: TLDR: Si vous utilisez Django 2.2, vous devez utiliser PSYCOPG <2.9 dans votre fichier d'exigences. Je peux comprendre leur point de vue, ce qui semble être que c'est que c'est Un cas de bord lié à un détail interne / implémentation et peut être corrigé en mettant à jour Django. J'apprécie grandement PSYCOPG2 et comprenons qu'il ne sera pas "fixé" par Psycopg2.
Pas une option sur M1 Mac pour utiliser 2.8.6 .. il ne compilera pas :(
Merci! Je l'ai résolu pour moi aussi!
Merci! Cela a résolu mon problème sur Github CI (alors que tout fonctionnait bien à la fois localement et localement à l'intérieur du Docker).
J'ai résolu ceci en mettant à niveau Django au lieu de rétrograder PSYCOPG. Je ne sais pas quelle version résout exactement le problème, mais 3.2 le fait certainement.
La réponse acceptée est obsolète maintenant et vous devriez décider de ne pas rétrograder si vous avez la possibilité de mettre à niveau Django à la place.
La réponse acceptée est pas obsolète, comme de nombreux commentaires récents à ce sujet l'indiquent. La mise à niveau de Django n'est pas une tâche triviale et doit être soigneusement pesée contre la solution de contournement temporaire de la dégradation mineure de la version PSYCOPG2 qui fonctionne toujours à ce jour (sauf s'il devient essentiel de mettre à niveau PSYCOPG2 pour d'autres raisons telles que ces autres comme sécurité).
Il est toujours utile, mais néanmoins obsolète pour ceux qui peuvent se permettre la mise à niveau, et probablement PSYCOPG2 sera mis à jour pour résoudre le bogue à un moment donné, si ce n'est pas déjà fait (je n'ai pas vérifié). Si pour résoudre un problème que vous pouvez mettre à niveau ou rétrograder, mon argent sera toujours sur la mise à niveau.
Le rétrogradation de la mise à niveau n'est pas le même «poids». L'une est une fonction d'utilité qui obtient une mise à jour de fonctionnalité (2.8.x à 2.9.x). L'autre est un cadre Web complet qui passe de 2.x à la version majeure 3.x, avec des changements de rupture connus. C'est Major Travail. Si vous n'aviez pas fait cette affirmation selon laquelle la réponse acceptée est mauvaise, vous n'auriez pas obtenu de remarque de moi, le vôtre est par ailleurs une bonne réponse. En l'état, je détesterais que quelqu'un de nouveau et impressionnable soit mis sous pression sur une mise à niveau prématurée et insuffisamment planifiée de Django.
Je ne conseille pas nécessairement de mettre à jour la version principale, 3.2 est tout simplement celle que j'ai mise à jour et donc la seule que je puisse confirmer fonctionne, mais une mise à jour dans la gamme 2.x pourrait également faire l'affaire. Quiconque veut expérimenter peut le faire et mettre à jour ma réponse, les utilisateurs moins aventureux peuvent suivre les autres réponses et rétrograder PSYCOPG si, comme je le note dans ma réponse, ils n'ont pas la possibilité de mettre à niveau. Je considère la réponse acceptée obsolète car elle encadre le rétrogradation comme la solution uniquement , ce qui n'est plus.
J'ai eu le même problème et je l'ai corrigé en supprimant simplement cette ligne de mon fichier paramètres.
À partir d'un test rapide, je peux confirmer que use_tz = false corrige en effet le problème de connexion PSYCOPG2 (psycopg2 == 2.9.3). Cependant, et c'est probablement la raison de la vote Down, cela pourrait causer toutes sortes d'autres problèmes avec d'autres parties de Django en attendant de sensibilisation au fuseau horaire et modifierait la nature des données d'horodatage (je m'attends à ce qu'elle ne fasse pas plus loin Les tests au-delà de la vérification de la connexion fonctionnaient aux données lecture ).
C'est ce que je travaille pour que tout cela fonctionne django 2.2.x (qui n'est pas compatible avec psycopg2> = 2.9.0 :
brew install libpq --build-from-source brew install openssl brew link openssl export LDFLAGS="-L/opt/homebrew/opt/openssl@1.1/lib -L/opt/homebrew/opt/libpq/lib" export CPPFLAGS="-I/opt/homebrew/opt/openssl@1.1/include -I/opt/homebrew/opt/libpq/include" echo 'export PATH="/opt/homebrew/opt/openssl@3/bin:$PATH"' >> ~/.zshrc brew install postgres pip install psycopg2==2.8.6
Je suis sur BigSur sur un M1 MacBook.
Il résout mon problème, macos monterey m1, merci
Assurez-vous d'avoir activé votre environnement virtuel si un cas vous l'avez désactivé (veuillez vous assurer que vous êtes dans l'environnement virtuel)
Pour activer votre environnement virtuel, utilisez cette commande: Nom de la source de l'Env / bin / Activer Virtual
Est-ce que cela répond à votre question? django 1.9.2 AssertionError: la connexion de la base de données n'est pas T réglé sur UTC
Cela ne m'a pas aidé à résoudre ma réponse. J'ai essayé toutes les manières mentionnées dans cette question, mais ma requête n'a pas résolu.
Je suis confronté à exactement le même problème, et il est apparu hier. Pouvez-vous essayer
use_tz = falsedans vos paramètres et confirmer qu'il "corrige" l'erreur? Btw j'ai cette erreur avec Django 2.2.13 et Postgres 11Je suis confronté au même problème, ce qui s'est produit hier. La définition du
use_tz = falsel'a résolu mais je ne sais vraiment pas ce qui s'est passé.postgres = # select * from pg_timezone_names où le nom comme 'utc'; Nom | ABREV | utc_offset | IS_DST ------ + -------- + ------------ + -------- UTC | UTC | 00:00:00 | f