> 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.
That's exactly what I do. The only thing that you should do (in my opinion) is to implement some basic tzinfo for UTC and optionally use it when instantiating datetime value for a DateTime field. e.g. my_datetime = models.DateTimeField(utc_tzinfo = True, ... ) and when a model is fetched, this time field would no longer be 'naive', and could be easily converted to user's local time (using pytz or other library). No extra tricks needed. It would solve the problem for 99% people who deal with timezones, because I guess everyone who wants it done properly, stores all times as UTC. -- 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.
