Thanks for the tip on pytz. It might be what I need.
See django-timezones, django-related helpers around pytz:
http://github.com/brosner/django-timezones
its LocalizedDateTimeField model/form fields construct non-naive python
datetimes with pytz tzinfo.
(see its tests.py for some additional simple examples)
It's basically indispensable for us, even though we really only use one
(non-UTC) timezone, just to deal with the idiocy that is DST.
As for the other part of your note, I completely agree with the sentiment.
> The problem is that, in a standard Django installation, there's
> an inherent timezone defined in settings.py.
Set django's settings.TIME_ZONE = 'UTC' and work in utc internally*.
Seriously.
Django will then (try to - watch out for shared apache [1]) 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... use django-timezones (django helpers around pytz) to localize
user-facing time and accept local time inputs.
* Don't use windows on the server, if you are, set the os/system clock
to utc too and live with it.
[1] http://groups.google.com/group/django-users/msg/6c5e88adfcd2b65f
--
You received this message because you are subscribed to the Google Groups "Django
users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
