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

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 :-)

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.

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.

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.

See also, #2315

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.

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.

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

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

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.

Milestone post-1.0 deleted

Not sure why this was assigned to multidb.

Patch updated to r12590 (fixed docs merge conflict)

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

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