Code

Opened 8 years ago

Closed 4 years ago

Last modified 3 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, rizumu, jedie, bas@…, gabrielhurley 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 6 years ago.
t1480-r7662.diff (4.6 KB) - added by ramiro 6 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 6 years ago.
1480-r12590.diff (6.4 KB) - added by ramiro 4 years ago.
Patch updated to r12590 (fixed docs merge conflict)

Download all attachments as: .zip

Change History (30)

comment:1 Changed 8 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 8 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 8 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 8 years ago by URL

  • Type defect deleted

comment:5 Changed 8 years ago by ubernostrum

  • Type set to 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 7 years ago by SmileyChris

  • Triage Stage changed from Unreviewed to Design decision needed

See also, #2315

comment:7 Changed 7 years ago by mtredinnick

  • Triage Stage changed from Design decision needed to Accepted

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 6 years ago by ramiro

comment:8 Changed 6 years ago by ramiro

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 6 years ago by ramiro

  • Has patch set

Changed 6 years ago by ramiro

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

comment:10 Changed 6 years ago by anonymous

  • milestone set to 1.0

comment:11 Changed 6 years ago by korpios

  • milestone changed from 1.0 to post-1.0

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

Changed 6 years ago by ramiro

comment:12 Changed 5 years ago by ramiro

  • Owner changed from nobody to ramiro

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 5 years ago by anonymous

  • milestone post-1.0 deleted

Milestone post-1.0 deleted

comment:14 Changed 5 years ago by ramiro

  • Cc ramiro added

comment:15 Changed 5 years ago by anonymous

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

comment:16 Changed 5 years ago by rizumu

  • Cc rizumu added; ramiro removed

comment:17 Changed 5 years ago by rizumu

  • Cc ramiro added

comment:18 Changed 5 years ago by jedie

  • Cc jedie added
  • Owner changed from ramiro to jedie
  • Status changed from new to assigned

comment:19 Changed 5 years ago by russellm

  • Version changed from soc2009/multidb to SVN

Not sure why this was assigned to multidb.

comment:20 Changed 4 years ago by anonymous

  • Cc bas@… added

comment:21 Changed 4 years ago by gabrielhurley

  • Cc gabrielhurley added

comment:22 Changed 4 years ago by philz42

  • Cc philz42 added

comment:23 Changed 4 years ago by russellm

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Triage Stage changed from Accepted to Ready for checkin

Changed 4 years ago by ramiro

Patch updated to r12590 (fixed docs merge conflict)

comment:24 Changed 4 years ago by russellm

  • Resolution set to fixed
  • Status changed from assigned to closed

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

comment:25 Changed 4 years ago by russellm

(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 3 years ago by jacob

  • milestone 1.2 deleted

Milestone 1.2 deleted

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.