HTML date format and Date.parse()

Jason Orendorff 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 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


More information about the es-discuss mailing list