On Fri, Apr 9, 2010 at 3:20 PM, Tom X. Tobin <tomxto...@tomxtobin.com> wrote: > > 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
We've solved this particular hurdle in r12602 when fixing bug #1480 but of course more work is needed for a full solution. > > 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. We added this featur as an idea for this year GSoC program http://code.djangoproject.com/wiki/SummerOfCode2010#Multipletimezonesupportfordatetimerepresentation So far, no student expressed interest in it, maybe we can propose it as a feature for 1.3 when the time comes. Regards, -- Ramiro Morales | http://rmorales.net -- 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.
