Can't change TIME_ZONE after initial transaction in PostgreSQL

[Calvin Spealman]

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.

[Calvin Spealman]

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

[Calvin Spealman]

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

[Aymeric Augustin]

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

See ​https://docs.djangoproject.com/en/dev/topics/settings/#altering-settings-at-runtime

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

[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.

[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.

[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.

[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.