On Tue, Apr 30, 2013 at 4:34 PM, Allen Wirfs-Brock
<al...@wirfs-brock.com> wrote:
>>> Or maybe we should both just stick to a valid subset of ISO 8601.
>>
>> Do you mean: achieve consistency by having HTML retract its extensions
>> to ISO 8601? I'm pretty sure that ship has sailed.
>
> Strictly speaking, so has ES55/5.1's date format.
There's a difference, though, between adding and removing
functionality. Adding support for spaces in 15.9.1.15 is
backward-compatible. Removing support for spaces from HTML, as you
propose, wouldn't be.
> ES6 annex B is the appropriate place to define browser host web reality
> extensions to Date.parse.
I'm proposing a one-line change to 15.9.1.15 (allow a space in place
of 'T') and an equally minor change to 15.9.1.15.1 (extended years),
plus a sentence or two of rationale. The proposal has nothing to do
with the unspecified legacy formats.
I agree it'd be nice to get the intersection of those formats
documented, but it's a tangent.
> For that reason, it would probably be better to define "static" methods for
> parsing specific formats. For example,
> Date.parseHTMLDate(str) //only recognizes whatever HTML defines
The reason I propose changing 15.9.1.15 is to have one *less* thing to
remember. To unify, since we actually have an opportunity to do that
here, for once!
Why is it important to have Date.parse("2013-01-01 10:30Z") return NaN?
-j
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
