I just wanted to chime in with a couple of extra notes here. I won't comment on most of it as I think it's all spot on :)
On Sep 3, 10:40 pm, Aymeric Augustin <aymeric.augus...@polytechnique.org> wrote: > Django should use timezone-aware UTC datetimes internally > ......................................................... > > Example : datetime.datetime(2011, 09, 23, 8, 34, 12, tzinfo=pytz.utc) There is also a Django time field. How to handle this is kind of hard as having a timezone on a time field may not make much sense. At the moment it is up to application code to combine this with a date in a sane manner. If Django switches to use UTC internally then this is going to become harder for many users to do correctly. Maybe some library functions that will help them to do this will work? Using UTC internally isn't enough in the way that using Unicode internally is to mean that application writers can factor out time handling in global applications. For example, if I have a Django application that tracks retail sales worldwide then a report of sales figures for any given day probably needs to use the correct local time at each store to make sense from a business perspective. Using UTC internally may however make developers aware that there is an issue for them address earlier -- a good thing. The other thing that ought to be thought about with this is the admin time/date widgets which have the 'now' link. This is always filled in with the browser's current time which plays havoc when admin is used by a user in a different time zone to the site's settings. It should be possible to capture the UTC offset along with the time so that the correct number of minutes is added/subtracted when the field is processed by Django. Thankfully daylight savings can be ignored here. Many browsers will send the local time of the request to the server. This can be used to guess the correct timezone, but it won't get things right (there's no way to work out the correct DST setting from this). If the country can be identified in some way then the two together should be good for most users. The UTC offset in the request is all that's needed to get localize any times that are sent back though as again, daylight savings can be ignored -- so long as we aren't rash enough to presume that this offset tells us the actual time zone. Hope this is useful, Kirit -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
