HTML date format and Date.parse()
jason.orendorff at gmail.com
Wed May 1 08:45:34 PDT 2013
On Tue, Apr 30, 2013 at 4:34 PM, Allen Wirfs-Brock
<allen at 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 126.96.36.199 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 188.8.131.52 (allow a space in place
of 'T') and an equally minor change to 184.108.40.206.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 220.127.116.11 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?
More information about the es-discuss