Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#17213 closed Bug (wontfix)

Can't change TIME_ZONE after initial transaction in PostgreSQL

Reported by: Calvin Spealman Owned by: nobody
Component: Database layer (models, ORM) Version: master
Severity: Normal Keywords:
Cc: Triage Stage: Unreviewed
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


The changeset from #3459 has SET TIME ZONE only executed for new connections, which breaks any code which changes settings.TIME_ZONE, such as live settings applications or per-request middleware implementations. The connection should allow other code to tell it "I'm changing things, re-do the settings statements on the next transaction.

Attachments (1)

17213.diff (4.1 KB) - added by Calvin Spealman 5 years ago.
Patch that adds a way to flag when the connection shoudl set once-only things again, and a test for it.

Download all attachments as: .zip

Change History (7)

Changed 5 years ago by Calvin Spealman

Attachment: 17213.diff added

Patch that adds a way to flag when the connection shoudl set once-only things again, and a test for it.

comment:1 Changed 5 years ago by Calvin Spealman

Component: UncategorizedDatabase layer (models, ORM)
Has patch: set
Needs documentation: unset
Needs tests: unset
Patch needs improvement: unset

I'm sure the way I've added control to set these flags on-demand might need changed, but its a proof-of-concept

comment:2 Changed 5 years ago by Aymeric Augustin

Resolution: wontfix
Status: newclosed

You should never alter settings at runtime, and we won't add code to Django to support that.


Would time zone support resolve your problem? (see last comment on #2626)

Last edited 5 years ago by Aymeric Augustin (previous) (diff)

comment:3 Changed 5 years ago by Calvin Spealman

While I'm very happy to see #2626 moving forward, I don't think it will be helpful in the context I've seen #17213 needed, which are installations running more sites than can realistically be served with at least one process per site, and some sort of middleware is used before each request to load per-site settings. I understand the dislike of changing settings, and I agree with it. i only filed this ticket, because it seemed that #3459 had broken a previous behavior and I could not determine if this was intended or desirable. I'm not sure the best course of action for such setups in the future, but will give it some thought.

comment:4 Changed 5 years ago by Aymeric Augustin

In fact, you're looking a larger problem than just time zone settings. (Massive) multi-hosting isn't supported by Django at this time. While it sort of works (some third party libraries exist to support this use case), our current position is that changing settings at runtime may cause undefined behavior.

comment:5 Changed 5 years ago by anonymous

It would be possible to support changing the connection timezone for every cursor.execute() if it needs changing, using get_parameter_status (see #17266). Although I do agree with aaugustin: you should not change settings, except in testing using override_setting.

comment:6 Changed 5 years ago by Aymeric Augustin

The connection_created signal may be useful in you want to change the time zone on a per-request basis.

I think setting TIME_ZONE = None in the settings file and executing SET TIME ZONE in a signal receiver should work. That function will have to look up the time zone in a global (thread-local) variable.

Note: See TracTickets for help on using tickets.
Back to Top