I've created a ticket to propose a little change in the documentation : https://code.djangoproject.com/ticket/16392
Yohan 2011/6/29 Yohan Boniface <yohanbonif...@gmail.com> > 2011/6/28 Stephen Burrows <stephen.r.burr...@gmail.com> > >> >> The "O" formatter - or more specifically, the "Z" formatter - does >> include that bit of magic. Is there a particular reason for this? >> > > I ask myself the same question. Why for the "Z" (and co) and not for the > "c" ? > > >> Also, if a timezone is assumed, wouldn't it make more sense to assume >> the timezone of the project rather than UTC? Rather than noting an >> inconsistency, can we make this consistent? > > > Defining the default behaviour when the datetime is naive is not that easy, > in my point of view. > > Here is the summary of what I understand (we are talking about the Django's > dateformat util) : > > 1. when the datetime has a timezone, use it : this is what Django does, and > it's fine. > => In my point of view, the documentation should be clearer (about the fact > that the "c" formatter, using isoformat, will add the timezone offset only > for non naive datetime and about the fact that this behaviour is not > consistent with other formatters) > => I'll propose some little patch > > 2. when the datetime is naive, what to do ? > => like I said, I think the answer is not that easy, and Django is not > completely coherent on the subject > > 2.1 Do nothing > => this is what Django does for the "c" formatter (as using the > .isoformat datetime method) [1] > => easier, clearer (no magic), but not so user friendly : it means that > when dealing with naive datetimes, developpers have to manually add the > timezone everytime (error-prone, not very DRY...) > > 2.2 Use the system local timezone > => this is what Django does for the "Z" and "O" formatters for example > (using the time.timezone / .altzone function) [2] [3] > => basing the default timezone on the machine local one could be risky > (and not so "cloud" aware...) > > 2.3 Use the settings.TIME_ZONE information > => I wonder why this setting is not used by Django here > => in theory, this sounds like a good default behaviour > > 2.4 Missing something ? > > And so the final question is : is there a "good" way to arbitrate the > handling of naive datetime when formatting them ? > > [1] > https://code.djangoproject.com/browser/django/trunk/django/utils/dateformat.py<https://code.djangoproject.com/browser/django/trunk/django/utils/dateformat.py#L126><http://piratepad.net/ep/search?query=L126> > #L126<https://code.djangoproject.com/browser/django/trunk/django/utils/dateformat.py#L126> > [2] > https://code.djangoproject.com/browser/django/trunk/django/utils/dateformat.py<https://code.djangoproject.com/browser/django/trunk/django/utils/dateformat.py#L269><http://piratepad.net/ep/search?query=L269> > #L269<https://code.djangoproject.com/browser/django/trunk/django/utils/dateformat.py#L269> > [3] > http://docs.python.org/library/time.html<http://docs.python.org/library/time.html#time.timezone><http://piratepad.net/ep/search?query=time.timezone> > #time.timezone <http://docs.python.org/library/time.html#time.timezone> > -- 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.
