On Feb 20, 10:59 pm, Aymeric Augustin <aymeric.augus...@polytechnique.org> wrote: > (subject changed because I'm forking the discussion) > > On 20 févr. 2012, at 21:29, Anssi Kääriäinen wrote: > > > Another question I have meant to ask is if 1.4 is too early to have > > USE_TZ = True as default setting? I am afraid there are still some > > bugs to iron out, some documentation to improve, helper functions to > > add and most of all the timezone handling might confuse new users. > > I was thinking about that too. > > The main reason for enabling time zone support by default in new projects > (through the settings.py template) was to store UTC in the database (on > SQLite, MySQL and Oracle; PostgreSQL always does that anyway). > > This decision was certainly skewed by my background in enterprise software, > where reliable handling of datetimes is a no brainer. But this isn't the most > common use case for Django. > > Python doesn't make it very easy to deal with time zones, so forcing that > concept on developers isn't friendly. The "right way" to do things is > impractical, and there isn't that much space for improvement. Besides, the > average website doesn't need time zone support, and IRC discussions show that > developers don't care. > > What do others think?
While I do not fall in the others category... I quickly grepped the source code for datetime. I think there are at least 30 lines (out of total 300) in the documentation which use datetime incorrectly. Likely more. I think the code isn't totally safe either. I don't think there is any way all of these can be fixed in time for 1.4. Of course, punting 1.4 further back is another option. In addition, database aggregation for example seems to be pretty hard to do correctly (group by date etc). For 1.5 I suggest a new module is added: django.utils.datetime. If USE_TZ is True, then it returns all the times (if at all possible) in UTC-aware datetime (actually datetime subclass instances). These datetimes would have at least one additional method: .as_localtime(). If USE_TZ is False, it is the same as Python's datetime module (maybe have localtime even in this case, it just returns self). That would make fixing the code and documentation much easier, just use from django.utils import datetime where you had used import datetime before. Search & Replace mostly. Supporting the module might be a little annoying, although datetime isn't exactly a fast-moving target (one "new in version 2.x" for each of 5, 6, 7), and most of the methods do not need overriding anyways. - 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.
