would anyone give insight on this datetime issue:
My web-application (on centos/apache/wsgi/django) shows different current time (datetime.datetime.now()
) from call to call - I'm not asking why the time keeps going ahead :)
I get the following in my debugging log: (please notice that first and last entries are made by the same process, but the latter one appears to be created five hours before the first one, which is nonsense)
2009-10-28 22:00:37,724 DEBUG pid=16436 time=2009-10-28 22:00:37.724682
2009-10-28 22:00:40,194 DEBUG pid=16407 time=2009-10-28 22:00:40.194602
2009-10-28 22:00:42,742 DEBUG pid=16409 time=2009-10-28 22:00:42.742598
2009-10-28 22:00:44,643 DEBUG pid=16408 time=2009-10-28 22:00:44.643639
2009-10-28 22:00:46,747 DEBUG pid=16436 time=2009-10-28 22:00:46.747777
2009-10-28 22:00:48,973 DEBUG pid=16411 time=2009-10-28 22:00:48.973176
2009-10-28 22:00:51,261 DEBUG pid=16410 time=2009-10-28 22:00:51.261172
2009-10-28 17:13:16,867 DEBUG pid=16436 time=2009-10-28 17:13:16.867307
Thanks!
You are likely running multiple applications in same process which are setting TZ differently. This can occur where using embedded mode and mixing it up with PHP applications in same Apache installation, or where have multiple Django instances running which want to set TZ differently.
Have a read of:
http://code.google.com/p/modwsgi/wiki/ApplicationIssues#Timezone_and_Locale_Settings
Solution is to use mod_wsgi daemon mode and delegate distinct Django instances with different TZ requirements to different daemon process groups.
To confirm, post more details about the way you are hosting your application. Ie., embedded mode vs daemon mode. Are you running multiple web applications, be they PHP or Python.
Note, am presuming that where you say WSGI you actually mean mod_wsgi. If you did, then please stop using term WSGI to refer to mod_wsgi. The Apache/mod_wsgi module is an implementation of the separate WSGI API specification. They are not the same thing.