On Fri, Apr 9, 2010 at 1:05 PM, Paweł Roman <romapa...@googlemail.com> wrote: > I've noticed that django always fetches 'naive' datetimes from the > database. Tzinfo property on a datetime object is always set to null, > even if the database stores a value WITH a timezone. > > This is a bit tedious because such datetime cannot be later converted > to any timezone. Each time I want to display a datetime on the screen > (converted to user's time zone) I have to copy it applying UTC as a > tzinfo (this is how it is stored in the database) and then convert to > relevant timezone with astimezone(). OK, that's one line of code :) > but I have a feeling that this line should be somewhere inside in the > django code.
This reminds me that we need to open-source our time zone code. We track entertainment events across several time zones, and Django's standard time handling can't cleanly deal with that. Database backends that store time zones as a UTC offset (e.g., PostgreSQL) actually cause *more* trouble because UTC offsets are not the same thing as time zones; it's always safest to store times as UTC and store the time zone separately. I'll try to push a rough cut of the time zone code to GitHub within the next 24 hours, and post the URL here; it's still going to need documentation and polishing. -- 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.
