datetime problems with Django application

[BEC]

I have a Django application running with mod_python on Apache. In
settings.py I have set TIME_ZONE="America/New_York". Within my
application I verify that os.environ['TZ'] is indeed set to this
value. Within my view.py I use datetime.datetime.now() to create a
time stamp that is stored in a model as a DateTimeField and viewed on
a rendered html page.

However, the times that I generate in my view are all off from what
they should be by five hours. I've changed the time zone around
"America/Chicago", "America/Anchorage" etc. no matter what I set
TIME_ZONE to, I get the same wrong time (5 hours off).

If I go to the admin page and use the change entry page to modify the
values stored in the database, the Time now link gives the correct
time?

Any idea on what is going on here? I'm particularly perplexed as to
why the admin page and my view are giving different times.

Brian

[Graham Dumpleton]

Do you run other Python or PHP applications in the same Apache? If you
do they likely have conflicting time zone requires.

The problem here is that TZ is a process wide setting and can only be
set to one value at a time. Thus, whatever application got to set it
last will take precedence.

See:

http://code.google.com/p/modwsgi/wiki/ApplicationIssues#Timezone_and_Locale_Settings

Use mod_wsgi daemon mode or fastcgi solutions, both of which can run
applications in their own processes if you are being afflicted with
this problem.

Graham

[Brian Chapman]

There may be another application setting the time zone, but my question still remains as to why the admin  page is getting the correct time but the view is not.

Brian

[David De La Harpe Golden]

BEC wrote:

> Any idea on what is going on here? I'm particularly perplexed as to
> why the admin page and my view are giving different times.
>

That does sound weird.

What database are you using?

Not an immediate help, but the sane way to handle timezones in django in
my experience:

(0) don't use windows on the server, if you are, set the system clock to
utc and live with it.
(1) preferably be using postgresql (good timezone handling)
(2) set django settings TIME_ZONE = 'UTC' and work in utc internally.
django will [try to, bearing in mind Graham's post] set TZ - and will
also tell postgresql to expect and return times in utc over the wire
(explicitly executes a "SET TIME ZONE" command in the connection).
django models.DateTimeFields become "timestamp with time zone"
postgresql fields, so your database now uses UTC timestamps that say
they are UTC and everything just works. Only now everything's in UTC...
so...

(3) use django-timezones (django helpers around pytz) to localize
user-facing time and accept local time inputs
http://github.com/brosner/django-timezones/

Even though my apps only really operate in one timezone, it's a $%^Łing
DST timezone (as is America/New_York), so the above is a real win.

Of course, you may be stuck dealing with a legacy db with non-utc
time.

[Brian Chapman]

At this stage, we just have some small applications using SQLite. I've noticed that I am always getting UTC despie what I set with time_zone. By last night I'd accepted the idea of using UTC internally and started looking into pytz to faciliate interface conversion, so I think I'm on the same track your suggesting. Still confused by the difference between view and admin. Thanks for your feedback.

Brian

On Wed, Nov 11, 2009 at 12:22 PM, David De La Harpe Golden <david.delah...@ichec.ie> wrote:

BEC wrote:

> Any idea on what is going on here? I'm particularly perplexed as to
> why the admin page and my view are giving different times.
>

That does sound weird.

What database are you using?

Not an immediate help, but the sane way to handle timezones in django in
my experience:

(0) don't use windows on the server, if you are, set the system clock to
utc and live with it.
(1) preferably be using postgresql (good timezone handling)
(2) set django settings TIME_ZONE = 'UTC' and work in utc internally.
django will [try to, bearing in mind Graham's post] set TZ - and will
also tell postgresql to expect and return times in utc over the wire
(explicitly executes a "SET TIME ZONE" command in the connection).
django models.DateTimeFields become "timestamp with time zone"
postgresql fields, so your database now uses UTC timestamps that say
they are UTC and everything just works.  Only now everything's in UTC...
so...

(3) use django-timezones (django helpers around pytz) to localize
user-facing time and accept local time inputs
http://github.com/brosner/django-timezones/

Even though my apps only really operate in one timezone, it's a $%^£ing

[Brian Neal]

On Nov 10, 5:41 pm, BEC <chapma...@gmail.com> wrote:
> I have a Django application running with mod_python on Apache. In
> settings.py I have set TIME_ZONE="America/New_York". Within my
> application I verify that os.environ['TZ'] is indeed set to this
> value. Within my view.py I use datetime.datetime.now() to create a
> time stamp that is stored in a model as a DateTimeField and viewed on
> a rendered html page.
>
> However, the times that I generate in my view are all off from what
> they should be by five hours. I've changed the time zone around
> "America/Chicago", "America/Anchorage" etc. no matter what I set
> TIME_ZONE to, I get the same wrong time (5 hours off).

Perhaps as Graham said there is a conflict with another application on
the server.

>
> If I go to the admin page and use the change entry page to modify the
> values stored in the database, the Time now link gives the correct
> time?

Explain this a bit more. You click on the little javascript thingy to
enter a time into the select box? Well that is purely client side.
That is your browser filling in the current time, not Django on the
server.

Regards,
BN