Opened 18 years ago

Closed 14 years ago

Last modified 7 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:
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: no UI/UX: no

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 16 years ago.
t1480-r7662.diff (4.6 KB ) - added by Ramiro Morales 16 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 15 years ago.
1480-r12590.diff (6.4 KB ) - added by Ramiro Morales 14 years ago.
Patch updated to r12590 (fixed docs merge conflict)

Download all attachments as: .zip

Change History (23)

comment:1 by hugo, 18 years ago

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 by marcink, 18 years ago

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 by marcink, 18 years ago

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 by James Bennett, 18 years ago

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 by Chris Beaven, 17 years ago

Triage Stage: UnreviewedDesign decision needed

See also, #2315

comment:7 by Malcolm Tredinnick, 17 years ago

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.

by Ramiro Morales, 16 years ago

Attachment: 1480_time_zone.diff added

comment:8 by Ramiro Morales, 16 years ago

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 by Ramiro Morales, 16 years ago

Has patch: set

by Ramiro Morales, 16 years ago

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

by Ramiro Morales, 15 years ago

Attachment: t1480-r9690.diff added

comment:12 by Ramiro Morales, 15 years ago

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:14 by Ramiro Morales, 15 years ago

Cc: Ramiro Morales added

comment:16 by Thomas Schreiber, 15 years ago

Cc: Thomas Schreiber added; Ramiro Morales removed

comment:17 by Thomas Schreiber, 15 years ago

Cc: Ramiro Morales added

comment:18 by jedie, 14 years ago

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

comment:20 by anonymous, 14 years ago

Cc: bas@… added

comment:21 by Gabriel Hurley, 14 years ago

Cc: Gabriel Hurley added

comment:22 by philz42, 14 years ago

Cc: philz42 added

comment:23 by Russell Keith-Magee, 14 years ago

Triage Stage: AcceptedReady for checkin

by Ramiro Morales, 14 years ago

Attachment: 1480-r12590.diff added

Patch updated to r12590 (fixed docs merge conflict)

comment:24 by Russell Keith-Magee, 14 years ago

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 by Russell Keith-Magee, 14 years ago

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

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