On Nov 18, 5:31 pm, Aymeric Augustin <aymeric.augus...@polytechnique.org> wrote: > Hi Anssi, > > 2011/11/18 Anssi Kääriäinen <anssi.kaariai...@thl.fi> > > > So, at least according to this simple test there is nothing to > > worry about performance-wise. > > Thanks for the performance tests! They were still on my TODO list.
The tests could be better... It might be worth it to write something testing this into djangobench. I just don't know which branch is the current one :) > If you're using aware datetimes internally, user input is the only source > of naive datetimes in local time. Ambiguous values are handled properly by > a validation error:http://myks.org/stuff/django-tz-demo-2.png My point is that it would be very useful to know you are actually using aware datetimes internally. Especially when migrating an old project to use this feature, it is easy to miss some places that do not use aware datetimes. And you might find it out when you hit an hour where suddenly your webapp is failing all over the place. So the setting I proposed would report usage of naive datetimes all the year, so that you could spot the problems in testing, not in production. > > One idea is to use "SELECT col AT TIME ZONE 'GMT+2' as col". This way > > the session time zone doesn't need to be changed. For example: > This looks interesting, although I don't know how difficult it would be to > integrate in the ORM. > > I'm going to create a ticket and post your research there. This is easy as far as writing the cast goes (a couple of lines in backend/operations should do the trick), the problem is that columns do not support parameters for the SQL, and fixing this will need to touch n+1 places. Although allowing column parameters would be useful in the long run even without the timezone problem. Aliasing the columns properly could be a problem, too. It could be possible to get rid of the SET TIME ZONE at the start of new connections completely. This would save a couple of network round trips for every connection. Although there might be some small backwards compatibility problems for users using raw SQL... > It is now :) Nice! And thank you! - Anssi -- 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.
