Opened 9 years ago

Closed 4 years ago

#7062 closed Bug (invalid)

Multiple projects with different TIME_ZONE settings under mod_python can cause unexpected date/time behaviour

Reported by: durdinator Owned by: nobody
Component: Core (Other) Version: master
Severity: Normal Keywords: mod_python time timezone
Cc: me@…, nreilly@… Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: yes
Easy pickings: no UI/UX: no


When running Django under mod_python, if there are multiple projects running with different TIME_ZONE settings, this can under some circumstances lead to the time zone (and hence the value returned by being different for subsequent requests to the same URL.

We encountered this problem running Apache 2.0 with the prefork MPM, with 10 subprocesses. While most of the numerous Django projects on the server had TIME_ZONE = 'Europe/London' in the settings module, two had inadvertently been left with TIME_ZONE = 'America/Chicago'. After investigating a problem where a time-based query would return unexpectedly different results for repeated requests, we found that was mostly returning the local time value (10.05 am), but occasionally returning the wrong time (4.05 am). This 6 hour difference, not coincidentally, is the current difference between the America/Chicago and Europe/London time zones. Another instance of this problem was described in

Since the environment is maintained for each Apache subprocess, modifying it via os.environ in one subinterpreter causes the modified environment to be visible in other subinterpreters, which may be serving a different site. This causes a problem at present, as os.environ['TZ'] is set only once per project, when the settings are first loaded:

If the TZ environment variable were set per request (as is done with DJANGO_SETTINGS_MODULE and other environment variables passed through from the apache config via SetEnv commands), then the correct time zone setting would be available for each project. I have attached a patch against SVN HEAD to do this in the mod_python handler.

Until this is corrected, a workaround is:

  • Ensure that all django projects running under mod_python are using the same TIME_ZONE setting
  • Or if different time zones are required, then ensure that the apache config uses SetEnv to set the correct TZ variable for every project.

Attachments (1)

patch_tz.diff (908 bytes) - added by durdinator 9 years ago.

Download all attachments as: .zip

Change History (12)

Changed 9 years ago by durdinator

Attachment: patch_tz.diff added

comment:1 Changed 9 years ago by durdinator

Needs documentation: unset
Needs tests: unset
Patch needs improvement: unset

It is possible that a similar patch would need to be applied to, but I am not sure when that handler would get called relative to the core handler.

comment:2 Changed 9 years ago by grahamd

Setting TZ per request will not necessarily help. This is because it isn't the TZ value from os.environ that is necessarily the problem but the TZ variable returned by C getenv() function as it is this which is used by C library time functions.

Although when os.environ is updated, C environment variables are also updated, doing this per request isn't going to help and will only result in thread race conditions when done in a multithread Apache MPM. The results therefore may even be more unpredictable.

The only way you can safely run distinct Django instances with different time zone settings is to run them in separate processes using something like mod_wsgi daemon mode or fastcgi.

comment:3 Changed 9 years ago by durdinator

No, setting the environment variables per request obviously won't help if using the threaded MPM; but Django shouldn't be used with that anyway; see for more on that.

However, setting it per request and calling time.tzset() (as the patch does) will work with the prefork MPM.

comment:4 Changed 8 years ago by Simon Greenhill

Patch needs improvement: set
Triage Stage: UnreviewedAccepted

comment:5 Changed 8 years ago by korpios

Check out #2626; if time zone handling is done at the Field level, these problems go away.

comment:6 Changed 8 years ago by korpios

This is solved by DateTimeZoneField in Bulbs; see my comment:

comment:7 Changed 8 years ago by anonymous

Cc: nreilly@… added

comment:8 Changed 6 years ago by Luke Plant

Severity: Normal
Type: Bug

comment:9 Changed 5 years ago by Aymeric Augustin

UI/UX: unset

Change UI/UX from NULL to False.

comment:10 Changed 5 years ago by Aymeric Augustin

Easy pickings: unset

Change Easy pickings from NULL to False.

comment:11 Changed 4 years ago by Aymeric Augustin

Resolution: invalid
Status: newclosed

Support for mod_python was removed in Django 1.5.

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