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. > This part of the documentation raises one question: > """ > Unfortunately, during DST transitions, some datetimes don't exist or > are > ambiguous. In such situations, pytz_ raises an exception. Other > :class:`~datetime.tzinfo` implementations, such as the local time zone > used as > a fallback when pytz_ isn't installed, may raise an exception or > return > inaccurate results. That's why you should always create aware datetime > objects > when time zone support is enabled. > """ > > Won't this lead to web applications where errors suddenly start > popping up all over the place, but only twice (or once?) a year? > 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 Since the hour of the DST switch is chosen to minimize human activity, this won't be an issue for most websites. UIs that allow entering unambiguous datetimes in local time aren't intuitive — basically, you need an "is_dst" checkbox. If you really need to enter non-ambiguous data in local time during the DST switch, you probably shouldn't be working in local time at all. Armies use UTC, for instance. > A setting "ON_NAIVE_DATETIMES=[do_nothing|log|error]" could be nice, > at least for testing. This way you could spot the errors early on. I > don't know if that would be too expensive performance wise, though. > During the ambiguous hour, we have the choice between guessing randomly and raising an exception. The Zen of Python says: "In the face of ambiguity, refuse the temptation to guess." That said, you can use your own tzinfo implementations if you want to customize that behavior. > 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: > > SET TIME ZONE 'UTC'; > > create table testt(dt timestamptz); > > insert into testt values(now()); > > select dt at time zone 'GMT+2' as dt from testt; > 2011-11-18 07:06:47.834771 > > > select dt at time zone 'Europe/Helsinki' as dt from testt; > 2011-11-18 11:06:47.834771 > > Oracle seems to have a similar feature [1]. I don't know if other > databases offer similar functionality. MySQL has probably support for > something similar when using TIMESTAMP columns. > > But as said, I don't see this as a major issue. It would be nice to > support this some day. > 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. I hope to see this in trunk soon. > It is now :) -- Aymeric. -- 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.
