ISO/JSON date format timezone questions

Lars T Hansen lth at acm.org
Tue Jul 17 15:48:30 PDT 2007


On 7/17/07, John Cowan <cowan at ccil.org> wrote:
> doekman at gmail.com scripsit:
>
> > This proposal also states the T in date/time is mandatory, and the
> > rest is optionally:
> >   timestamp ::= date? "T" time? tz?
> >
> > a bit odd. I'm glad there's a new version.
>
> In general the T is mandatory if a time follows: that differentiates
> 200707 (July 2007) from T200707 (20:07:07 on an unspecified date).

In ES4 the T is mandatory, period.  This is a little odd and conflicts
mildly with eg the W3C date note, which requires the T only if a time
is present.

This artifact is at least in part a result of wanting to be able to
distinguish ISO dates unambiguously from anything else that is passed
to Date.parse for its delectation (you'd be surprised), without trying
to specify more fully what Date.parse can accept.  If we did try to
specify Date.parse more fully it would be largely irrelevant -- all
the browsers have extensive heuristics, and all existing web pages
must continue to work.  So in practice, implementations will grok
2007-07 even if they are not required to, but only 2007-07T is
guaranteed to be parsed as an ISO date: without the T, you're at the
mercy of the implementation's heuristics.

(Historically, the mandatory T is also an artifact of an attempt to
get date literals into the language, but that proposal has been
rejected.)

The situation with dates is overall less than satisfactory, but
backwards compatibility binds us in significant ways and we feel
support for ISO dates at least lets good developers write code that is
unambiguous, a clear step forward from 3rd Edition.

An alternative to the mandatory T would be introducing a new parse
method (parseISO?), but in practice Date.parse() will have to handle
ISO dates regardless, so this is what we've come up with.

--lars



More information about the Es4-discuss mailing list