database connection isn't set to UTC

[plup]

tl; dr: if you are using Django 2.2 you must use psycopg < 2.9 in your requirements file.

---

I just add this error after an upgrade. It's probably right about my database not being in UTC but I don't see the problem.

venv/bin/pip install -U psycopg2
Collecting psycopg2
  Downloading psycopg2-2.9.tar.gz (379 kB)
     |████████████████████████████████| 379 kB 7.2 MB/s 
Building wheels for collected packages: psycopg2
  Building wheel for psycopg2 (setup.py) ... done
  Created wheel for psycopg2: filename=psycopg2-2.9-cp36-cp36m-linux_x86_64.whl size=473570 sha256=c01f7407f6cc56a729d8693eb62133f284c8612b0ae0ef109d8bfa01ba5441d6
  Stored in directory: /home/test2/.cache/pip/wheels/70/01/46/39007954b343d1d72463a755e6a74e6106b10748fe22e2058b
Successfully built psycopg2
Installing collected packages: psycopg2
  Attempting uninstall: psycopg2
    Found existing installation: psycopg2 2.8.6
    Uninstalling psycopg2-2.8.6:
      Successfully uninstalled psycopg2-2.8.6
Successfully installed psycopg2-2.9

[dvarrazzo]

Sorry, where is the error?

[coderanger]

Just spent a while debugging this, Psycopg 2.9 changed the value passed to tzinfo_factory from an int to a timedelta. Django 2.2 (possibly newer but I'm on 2.2) has a check for offset == 0 and since timedelta(0) != 0 it goes boom. Not sure what the path forward here is but that's the cause I think.

[dvarrazzo]

Uhm, I checked and I thought that the change wouldn't have affected django. Looking into it...

[coderanger]

Looks like Django removed the check in 3.1 when it added support for non-UTC DB timezones. Django 3.0 is no longer supported but 2.2 is for another year-ish so if not fixing this on this side we'll need a 2.2 patch release :)

[coderanger]

https://github.com/django/django/blob/2.2.24/django/db/backends/postgresql/utils.py is the code on the django side.

[coderanger]

Arguably this is outside the purview of Django LTS support so I think you could just say "not a conflict" and maybe Django notes the compat issue in a blog post or something, since the fix of pinning to 2.8.6 until getting to Django 3 is easy :D

[dvarrazzo]

I see. I can take a look. However I don't see exactly how to fix the problem.

The change was needed to support timezone with fractional minutes, otherwise timestamps in the past have an error of up to 30 sec. (#1272). The integer passed to FixedOffsetTimezone is a number of minutes so it didn't allow to use seconds, as the datetime.timezone module of Python 3.7 and following allows (of course FixedOffsetTimezone predates (datetime.timezone).

One option to fix the problem would have been to pass a number of seconds, but that would have been dangerous as it could have been misinterpreted. But because now the stdlib has a datetime object it seems right to offer the same interface.

If there is a way to fix it on our side (suggestions welcome) I'm happy to introduce a change. However if only Django 2.2 is affected I am tempted to suggest people to just stick to psycopg2 >= 2.8, < 2.9 in their requirements, as semver suggest to do, and have the issue fixed in a Django 2.2.x release, which might accommodate for the new value. Opening them a ticket and sending a MR...

[dvarrazzo]

https://code.djangoproject.com/ticket/32856#ticket

[coderanger]

Sounds good to me. Just one of the hazards of being on old versions of stuff :)

[dvarrazzo]

Sounds good to me. Just one of the hazards of being on old versions of stuff :)

More an hazard of not making use of semver, IMO. This is not a change that would have been pushed in a bugfix release: people who constrained the library to the major version shouldn't have found the problem. I bet the OP has just psycopg2 in their requirements file.

[coderanger]

2.8 to 2.9 is a feature release according to semver, not a major. For semver to catch this it would have had to be 3.0 instead. My pin was ~=2.8.

[dvarrazzo]

That sounds true, and this change seems indeed a semver violation, but relying on things not changing in versions which are more than a bugfix release is pretty fragile. I have had more breakages than I would like to remember assuming that nothing bad would have happened going from x.y to x.(y+1). If you don't need new features it's safer to specify >= x.y, < x.(y+1). Even more safer is to use Poetry or something similar (because breakages do happen in patch versions too).

I am looking forward to release psycopg 3, but that's a major rewrite, not a change in what I supposed to be an internal interface of an object predating the python datetime module (I don't think it was even documented that the object took an int number of minutes as constructor parameter).

[dvarrazzo]

MR ready in django/django#14530. Tests pass ok, see https://djangoci.com/job/pull-requests-bionic/database=postgres,label=bionic-pr,python=python3.8/12017/console

[MotasemAghbar]

Same issue with django 2.2.x, fixed by downgrade psycopg2 to 2.8.6.

Django Error: "database connection isn't set to UTC"

[elliottb303]

@plup Was on Django 3.0.5, and AWS RDS pg DB was set to UTC.. So a strange error.

Bumping Django to 3.2 and using psyopgg2 2.9.1 is looking good so far.

Django==3.2
psycopg2-binary==2.9.1

Django trace I was having for more info..
/usr/local/lib/python3.9/site-packages/django/db/backends/postgresql/utils.py in utc_tzinfo_factory
raise AssertionError("database connection isn't set to UTC")

[elkd]

Same issue with django 2.2.x, fixed by downgrade psycopg2 to 2.8.6.

Django Error: "database connection isn't set to UTC"

Just to highlight the conclusion for this issue, if you're on Django >=2.2.x, <3, you SHOULD PIN to Psycopg2 == 2.8.6.
Nah fix for ya!