Opened 11 years ago

Closed 7 years ago

Last modified 5 years ago

#1480 closed defect (fixed)

Don't Set TIME_ZONE unless it is explictly needed (or put it back to how you found it)

Reported by: Ian@… Owned by: jedie
Component: Core (Other) Version: master
Severity: normal Keywords:
Cc: philz42, Ramiro Morales, Thomas Schreiber, jedie, bas@…, Gabriel Hurley Triage Stage: Ready for checkin
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

Description

my understanding is that postgres needs the TIME_ZONE setting in order to work properly, and hence why it is in the settings.py file.

I just got bit by a nasty buy which was due to django setting/changing the timezone and then not setting it back to what it was after it was done. causing some pages to display CST and others to show PST (depending on weather the apache process had run a django request or not)

Is there a way django can either:
a) not set the time_zone expliclty and just use whatever the system says?
b) reset it back to what it was when it finishes up the request

Attachments (4)

1480_time_zone.diff (4.8 KB) - added by Ramiro Morales 9 years ago.
t1480-r7662.diff (4.6 KB) - added by Ramiro Morales 8 years ago.
Updated patch so it applies cleanly to trunk as of r7662 and adding New in Django development version note to documentation
t1480-r9690.diff (5.2 KB) - added by Ramiro Morales 8 years ago.
1480-r12590.diff (6.4 KB) - added by Ramiro Morales 7 years ago.
Patch updated to r12590 (fixed docs merge conflict)

Download all attachments as: .zip

Change History (30)

comment:1 Changed 11 years ago by hugo

Resetting it back won't work, as at least for the duration of the request you will have a switched timezone - so your problem would just change to "timezone depends on wether Apache at that moment serving something from Django in another thread". The problem is the global state of the timezone in the libc, so if Apache is running threaded, you get problems. It shouldn't be a problem with a full MPM installation, as in that case every process should have it's own timezone and since one process can just serve one request in that model, you should be safe.

The correct solution would be to move the timezone stuff away from the operating system and do all date/time handling in Django itself, at least if you want to be safe from thread-related timezone leakage :-/

Another option would be to switch away from mod_python to FCGI/SCGI with the process based FLUP server :-)

comment:2 Changed 11 years ago by marcink

I would vote for not setting TIME_ZONE at all, if possible. Setting the TZ environment variable on Windows is tricky, depends on the system language and is likely to break lots of time-related stuff like time.localtime and os.stat.

See my comment in #937 -- changing TZ causes problems with the autoreloader.

comment:3 Changed 11 years ago by marcink

See also #1119 and #1120 -- both are caused by trying to set TIME_ZONE on Windows.

hugo: threading is not the only problem here. Having a single global TIME_ZONE is similar to having a single global locale -- it is not enough when you have users living in different timezones.

comment:4 Changed 10 years ago by URL

Type: defect

comment:5 Changed 10 years ago by James Bennett

Type: defect

The problem with Apache is one that I've run into as well, and was rectified by using SetEnv in the httpd.conf to ensure that each virtual host had the correct TZ environment variable. I'm not sure what the best solution is for Django, though, because Django needs to have some way of ensuring that date and time functions return the correct values; re-inventing a whole set of time-zone conversion utilities within Django isn't something I'd be comfortable with.

comment:6 Changed 10 years ago by Chris Beaven

Triage Stage: UnreviewedDesign decision needed

See also, #2315

comment:7 Changed 10 years ago by Malcolm Tredinnick

Triage Stage: Design decision neededAccepted

This is hard to fix for all cases. It's not ideal that Django wants to set the timezone everywhere on shared systems, but it's also possible to work around as a few comments have indicated

The solution we should implement here is to allow the TIMEZONE setting to be None (or unset), in which case we will not attempt to set the timezone -- it will remain in the server's timezone -- and the client code is responsible for doing any timezone manipulations they want to do.

Changed 9 years ago by Ramiro Morales

Attachment: 1480_time_zone.diff added

comment:8 Changed 9 years ago by Ramiro Morales

I've added a patch implementing my interpretation of Malcolm comments. Includes modifications to the project setting template file doc blurb comment above the TIME_ZONE setting and for the settings.txt documentation file.

comment:9 Changed 9 years ago by Ramiro Morales

Has patch: set

Changed 8 years ago by Ramiro Morales

Attachment: t1480-r7662.diff added

Updated patch so it applies cleanly to trunk as of r7662 and adding New in Django development version note to documentation

comment:10 Changed 8 years ago by anonymous

milestone: 1.0

comment:11 Changed 8 years ago by korpios

milestone: 1.0post-1.0

Please don't change milestones just because you'd like to see something in 1.0.

Changed 8 years ago by Ramiro Morales

Attachment: t1480-r9690.diff added

comment:12 Changed 8 years ago by Ramiro Morales

Owner: changed from nobody to Ramiro Morales

Something that was left out on purpose from documentation in the modifications introduced by the patch is the possibility to unset TIME_ZONE (in addition to setting it to None) as suggested by some comments above. Thus, semantics are kept simpler:

  • The only available/documented way to direct Django to NOT touch the TZ environment variable is to set TIME_ZONE to None.
  • If is is left untouched in your settings file, then the default 'America/Chicago' value is used.

comment:13 Changed 8 years ago by (none)

milestone: post-1.0

Milestone post-1.0 deleted

comment:14 Changed 8 years ago by Ramiro Morales

Cc: Ramiro Morales added

comment:15 Changed 7 years ago by anonymous

milestone: 1.2
Needs documentation: set
Needs tests: set
Patch needs improvement: set
Version: soc2009/multidb

comment:16 Changed 7 years ago by Thomas Schreiber

Cc: Thomas Schreiber added; Ramiro Morales removed

comment:17 Changed 7 years ago by Thomas Schreiber

Cc: Ramiro Morales added

comment:18 Changed 7 years ago by jedie

Cc: jedie added
Owner: changed from Ramiro Morales to jedie
Status: newassigned

comment:19 Changed 7 years ago by Russell Keith-Magee

Version: soc2009/multidbSVN

Not sure why this was assigned to multidb.

comment:20 Changed 7 years ago by anonymous

Cc: bas@… added

comment:21 Changed 7 years ago by Gabriel Hurley

Cc: Gabriel Hurley added

comment:22 Changed 7 years ago by philz42

Cc: philz42 added

comment:23 Changed 7 years ago by Russell Keith-Magee

Needs documentation: unset
Needs tests: unset
Patch needs improvement: unset
Triage Stage: AcceptedReady for checkin

Changed 7 years ago by Ramiro Morales

Attachment: 1480-r12590.diff added

Patch updated to r12590 (fixed docs merge conflict)

comment:24 Changed 7 years ago by Russell Keith-Magee

Resolution: fixed
Status: assignedclosed

(In [12602]) Fixed #1480 -- Added the ability to use the system timezone. Thanks to Ramiro Morales for the patch.

comment:25 Changed 7 years ago by Russell Keith-Magee

(In [12603]) [1.1.X] Fixed #1480 -- Added the ability to use the system timezone. Thanks to Ramiro Morales for the patch.

Backport of r12602 from trunk.

comment:26 Changed 5 years ago by Jacob

milestone: 1.2

Milestone 1.2 deleted

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