"c" date formating and Internet usage

[Yohan Boniface]

Hi,

In Django's documentation, the 2 following points are mentionned [1]:

    - About date formating:

    "Uses the same format as PHP's date() function (http://php.net/date) with some custom extensions."

    - About the specific "c" format:

    "ISO 8601 Format." e.g. : 2008-01-02T10:30:00.000123

As we can see in the example, the ouput of the "c" format does not provide the time zone information (for example : +02:00).

Firstly, this is in contradiction with how PHP handles the "c" format : PHP does provide the time zone information (their documentation uses "2004-02-12T15:19:21+00:00" as the example for the "c" format [2]). Therefore, at the very least Django's documentation is innacurate.

Secondly, even if the ISO 8601 standard allows many date formats, the Internet usage is strongly oriented towards the use of the extended format with time zone (for e.g. 2008-01-02T10:30:00.000123+02:00). In particular:

    - In current HTML5 editor's draft [3], the W3C makes the time-zone offset mandatory for datetimes. A W3C note about the issue was also published. [4]

    - In their Sitemap protocol documentation, Google asks for the time-zone offset in datetimes, following the W3C Note. [5] [6]

 

    - The RFC 3339 says the following "the interoperability problems of unqualified local time are deemed unacceptable for the Internet." [7] Furthermore, it specifically mentions that date-time should be exprimed with the timezone offset. [8]

I suggest that Django follows this usage and modifies its handling of this format. However, since this clearly has backward compatibility issues, I'd like to have a discussion about this before proposing a patch.

Thanks,

Yohan

[1] https://docs.djangoproject.com/en/1.3/ref/templates/builtins/#date

[2] http://php.net/date

[3] http://dev.w3.org/html5/spec/common-microsyntaxes.html#valid-global-date-and-time-string

[4] http://www.w3.org/TR/NOTE-datetime

[5] http://www.sitemaps.org/protocol.php#lastmoddef

[6] http://www.google.com/support/webmasters/bin/answer.py?hl=en&answer=74288&from=42738&rd=1

[7] http://www.apps.ietf.org/rfc/rfc3339.html#sec-4.4

[8] http://www.apps.ietf.org/rfc/rfc3339.html#sec-5.6

[Stephen Burrows]

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

[Ian Clelland]

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
<clel...@gmail.com>

[Yohan Boniface]

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 <clel...@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-d...@googlegroups.com.
To unsubscribe from this group, send email to django-develop...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.

[Stephen Burrows]

I realize I may have been a little unclear. I assumed that this
problem was surfacing with relation to datetime fields on models,
which are inherently naive. (For example, an attempt to render a blog
entry's pubdate.) If the "c" formatting option were used in
conjunction with a timezone-aware datetime, then the UTC offset would
appear.

So I'm not saying that "Django doesn't support timezone-aware
datetimes". Django passes *all* of the work for the "c" formatting
option to python's datetime.isoformat() method, which *does* support
them. Sure, we could add some sort of magic that handles naive
datetimes, but I would argue against that on the principle that the
whole reason the datetimes are naive is that one doesn't know what
time zone they're from.

The "O" formatter - or more specifically, the "Z" formatter - does
include that bit of magic. Is there a particular reason for this?
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?

On Jun 28, 5:47 am, Yohan Boniface <yohanbonif...@gmail.com> wrote:
> 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...

> > <clell...@gmail.com>

[Yohan Boniface]

2011/6/28 Stephen Burrows <stephen....@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#L126

[2] https://code.djangoproject.com/browser/django/trunk/django/utils/dateformat.py#L269

[3] http://docs.python.org/library/time.html#time.timezone

[Yohan Boniface]

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 <yohanb...@gmail.com>