builtins: Check compatibility of ISO date proposal with other standards

[lth]

From the wiki:

I think we’re compatible with W3C time and date formats (http://www.w3.org/TR/NOTE-datetime) and webforms2 “time” input elements (http://whatwg.org/specs/web-forms/current-work/) but we should double-check that we are; no sense in being gratuitously incompatible for our major application area.

[lth]

W3C time:

We are not strictly compatible with the W3C time and date format because that format does not require the "T" when no time part is present. The W3C format presumably relies on applications knowing when they are seeing a date/time datum.

As a consequence, a W3C date cannot always be parsed as an ISO date in ECMAScript.

Additionally, the W3C time spec appears to imply that a time using the "+hh:mm" and "-hh:mm" time zone designators are always "local" time, even in the case of "+00:00", ie, it implies that there is perhaps some semantic difference between "+00:00" and "Z". But it does not pursue that. See following note about RFC 3339.

[lth]

RFC 3339:

We are compatible with the syntax of the RFC 3339 date-time nonterminal, which corresponds to a full ISO timestamp in ECMAScript 4, except that RFC 3339 allows the separator "T" and UTC designator "Z" to also appear in lower case.

As a consequence, a full RFC 3339 timestamp can be parsed by Date.parse only if first converted to upper case.

Further incompatibilities:

• The RFC allows the seconds field to have the value "60", and takes into account leap-seconds. E262-3 does not account for leap seconds and the ES4 draft is silent on the issue.
• The RFC gives some semantic meaning to the timezone offset "-00:00": it means the time is UTC and that no information is available about the local time offset, so even if the implementation would have preferred to produce a localtime plus offset, it can't.

[lth]

WHAT-WG:

We are compatible with the syntax for their datetime input type, which is an ISO time stamp with separators and all fields present and a Z suffix, all upper case.

We are not compatible with the syntax for their datetime-local input type, which always leaves off the timezone: the time zone is implicitly that of the computer running the program. However, this information can easily be recovered by creating a Date object and extracting its timezoneOffset member, and appending to a string, if parsing as an ISO date is required.

WHAT-WG has several other partial formats, which I'm ignoring here, because if parsing on such a fine level is desired it's easier for the application to extract the fields using a regular expression and create a new Date object from the result.

Thus we're basically compatible with the WHAT-WG spec.