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.
