On 7/17/07, John Cowan <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] 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 _______________________________________________ Es4-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es4-discuss
