I run a server with some PHP-powered forums (Vanilla 1.1.5a) on it, and I've recently noticed posts going out of order on them. Some digging revealed that Apache seems to be changing the current timezone back and forth from +0000 to -0500 on a request without apparent pattern, which can be seen in log entries like these: - - [15/Jun/2009:22:40:05 +0000] "GET /extensions/MembersList/library/paginate.js HTTP/1.1" 200 22880 "http://mysite.com/" "Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b99) Gecko/20090605 Firefox/3.5b99" - - [15/Jun/2009:17:40:05 -0500] "GET /extensions/JQuery/jquery-1.2.6.min.js HTTP/1.1" 200 55804 "http://mysite.com/" "Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b99) Gecko/20090605 Firefox/3.5b99"

Though the time adjusted for the timezone difference is the same, it seems to be causing PHP's date function to return the local, unadjusted time (with ensuing timewarp chaos happening in the forum's data).

I'm also running a Django-based mod_python application on the same VirtualHost. The config looks like this:

<VirtualHost *:80>
  ServerAdmin webmaster@localhost        
  DocumentRoot /var/www/

<Directory />
    Options FollowSymLinks
    AllowOverride None
<Directory /var/www/>
    Options Indexes FollowSymLinks MultiViews
    AllowOverride None
    Order allow,deny
    allow from all

ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
<Directory "/usr/lib/cgi-bin">
    AllowOverride None
    Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
    Order allow,deny
    Allow from all

    ErrorLog /var/log/apache2/error.log

# Possible values include: debug, info, notice, warn, error, crit,
# alert, emerg.
LogLevel warn

CustomLog /var/log/apache2/access.log combined

  Alias /doc/ "/usr/share/doc/"
  <Directory "/usr/share/doc/">
      Options Indexes MultiViews FollowSymLinks
      AllowOverride None
      Order deny,allow
      Deny from all
      Allow from ::1/128

  Alias /media/ "/usr/share/python-support/python-django/django/contrib/admin/media/"
  <Directory /usr/share/python-support/python-django/django/contrib/admin/media/>
              Options Indexes FollowSymLinks MultiViews
              AllowOverride None
              Order allow,deny
              allow from all

  RedirectMatch ^/raid-scheduler$ "/raid-scheduler/"
  <Location "/raid-scheduler/">
       SetHandler python-program
       PythonHandler django.core.handlers.modpython
       SetEnv DJANGO_SETTINGS_MODULE raid_scheduler.settings
       PythonOption django.root /raid-scheduler
       PythonDebug On
   PythonPath "['/opt', '/opt/raid_scheduler'] + sys.path"

Any ideas as to what might be causing this?


Could it be that some other request is setting TZ and it's being left lying around? Recording the getenv('TZ') at the start of every request would verify this, and putenv could be used to workaround it.

  • 1
    we used to run into this w/ $TZ and mod_perl...
    – jj33
    Jun 16 '09 at 1:15
  • I think that was exactly was going on. I'm going to dig around in my Django settings to see what's setting TZ, but using putenv to simply clear it at the start of each mod_php request seems to have put everything back in working order.
    – user9598
    Jun 16 '09 at 1:16

In Unix/Linux each process can operate in a different timezone. This is because depending on the content of $TZ variable that can be present in process's environment system time-related functions change their return values (this is neither PHP- or Apache-specific). Probably $TZ is getting modified inside one or more of your Apache processes. Both mod_php and mod_python are a part of Apache process, so they can freely modify $TZ.

Can you print getenv('TZ') to the log along with Apache process id via posix_getpid(), so it could be used to match with various user requests?


I think that has more to do with your php settings. Have a look at the mod_php "TZ" environment variable.


The TZ environment variable, as are various environment variables related to language and locale settings are process global. Thus running multiple application instances in the same process, whether they be Python or PHP, that want to set it differently will cause problems. This issue also affects mod_wsgi and is discussed in:


Note that trying to validate things by looking at os.environ from inside of a Python web application may not help as os.environ is a copy of process environment variables at time the Python (sub)interpreter instance was created. Thus, any change to TZ, or other environment variables will not be reflected in the Python os.environ dictionary. The only time synchronisation of specific values occurs is when a value in os.environ is updated, in which case Python also calls C level putenv() function.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy