Ian Hickson wrote:
On Fri, 5 Jun 2009, Julian Reschke wrote:
Ian Hickson wrote:
Michael(tm) Smith wrote:
It seems pretty clear that there isn't anything else to refer to for
the date/time parsing rules -- but to me at least, specifying those
rules seems orthogonal to specifying the date/time syntax, and I
would think the syntax could just be defined by making reference to
the productions[1] in RFC 3339 (instead of completely redefining
them), while stating any exceptions.
[1] http://tools.ietf.org/html/rfc3339#section-5.6
I think the exceptions might just amount to:
- the literal letters T and Z must be uppercase
Any technical reason why they have to?
Not really. We just need a separator.
So why make it different from RFC 3339?
Limiting the syntax to the simplest possible syntax was an intentional
design choice intended to ease the burden on implementors and authors. In
practice, pretty much every time we've made syntax case-insensitive, we've
ended up having trouble because of it.
If this was a totally new syntax, I would agree.
But as something based on ISO8601 (and thereby also RFC 3339) it appears
to be a bad idea to make it less compatible just for that reason.
- a year must be four or more digits, and must be greater that zero
"a year must be four or more digits" -- sounds like an alternative
format that an additional RFC, updating RFC 3339 could specify.
"must be greater that zero" -- that's not syntax :-)
So yes, I think referring to RFC 3339, even if it's just a narrative
mention, would be good.
Why?
Because it explains to readers how this is different. That is important
because it's natural to look for existing libraries to parse date formats.
The HTML5 spec defines exactly how to parse dates. Implementors are
required to implement what the spec describes, so reusing libraries is
implicitly not likely to be useful here. RFC3339 isn't even a particularly
important one in the grand scheme of things (ISO8601 comes to mind as a
much higher-profile example).
I think it's unfortunate that HTML5 doesn't allow using an off-the-shelf
parser. But if it doesn't, and the temptation *will* be there to use
them, I'd recommend stating it very clearly.
I'm certainly not proposing to go through every date format spec and
explain how the rules in HTML5 differ from those rules. That is the kind
of material that belongs in support documents.
BR, Julian
