Hi Stephen, Hi Ian, Hi all, As you say Stephen, isoformat is handling the timezone offset for non naive datetime, and so does Django in the "c" date formatter. And I should have noticed and mentionned this in my previous email. I'll take the time to give a better look to this issue, with these new elements. By the way, I wonder why for the "O" formatter a workaround is used when the datetime is naive, and not for the "c" formatter. Anyway, I think that at least a little patch to the doc to clarify the "c" behaviour should be useful (naive and non naive datetime). And maybe to warn about the non consistent behaviour of Django depending on the date formater used.
Yohan 2011/6/27 Ian Clelland <clell...@gmail.com> > On Sun, Jun 26, 2011 at 12:27 AM, Stephen Burrows < > stephen.r.burr...@gmail.com> wrote: > >> This is related to the recent discussion about timezone-aware datetime >> storage [1] and how django doesn't do it. Since the date filter's "c" >> argument is handled with python's datetime.isoformat() [2] timezone- >> naive datetimes will not display a UTC offset. >> >> [1] >> http://groups.google.com/group/django-developers/browse_thread/thread/76e2b486d561ab79/0a46b72da6e9fb03 >> >> [2] >> http://docs.python.org/library/datetime.html#datetime.datetime.isoformat >> >> > This isn't the same issue at all -- It may be related, but that discussion > thread was about storing timezone-aware timestamps in the database, not > about handling them in templates. > > <strawman-alert />We can't simply say that "Django doesn't support > timezone-aware datetimes" -- besides being a ridiculous restriction, it's > not true: even in django.utils.dateformat there are several formatting codes > that take the input's timezone into account (see I, o, T, U). > > Even the "r" formatting code, for RFC 822 formatting, takes the timezone, > if present, into account. > > While I would use the documented claim of PHP compatibility as an argument > for this, it's not really a strong argument (and I wouldn't support just > removing the claim as a simple solution). A better argument is that the ISO > standard allows the timezone, various Internet standards and drafts > recommend or require it, and in many cases, it is available to Django, and > so we should include it when we can. > > I generally find myself having to introduce a "proper" ISO-8601 formatting > string into every project, or supplement the time rendering with a > hard-coded timezone, when I can know it for sure (e.g., {{ > timestamp|date:"c" }}+00:00 ). I would absolutely support adding a "real" > ISO-8601 formatter to the standard filter library. > > -- > Regards, > Ian Clelland > <clell...@gmail.com> > > -- > 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. > -- 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.
