Proposal seeking champion: Uniform parsing of quasi-standard Date.parse input

Richard Gibson richard.gibson at
Sat Jun 30 00:08:18 UTC 2018

I saw that, but the links are dead, it appears to be abandoned, and the
goals don't quite align with what I'm trying to address. As I noted,
specifying what must be accepted is only half of a solution (and frankly,
the current state of what gets accepted is pretty good). But I believe it's
also important to specify what must be *rejected*. Think of it like an
error-correcting grammar.

On Friday, June 29, 2018, Jordan Harband <ljharb at> wrote:

> See also
> On Fri, Jun 29, 2018 at 1:01 PM, Richard Gibson <richard.gibson at>
> wrote:
>> TL;DR:
>> hange-date-parsing
>> A conversation bubbled up on IRC a while back about how implementations
>> handle unusual Date.parse input, and I've been thinking about it on and off
>> ever since. It turns out that engines are all over the place for input that
>> is just a little bit off from the ECMAScript interchange format, even when
>> such input is valid ISO 8601.
>> That rubs me the wrong way, because guaranteeing proper processing for
>> conforming input but not guaranteeing rejection of nonconforming variations
>> on it is a half solution. For example, only Edge accepts
>> "2018-06-28T24:01:01Z" (use of hour 24 for other than end-of-day), only
>> Safari accepts "2015-06-30T23:59:60Z" (use of 60 for seconds), and only
>> Chrome accepts "2018-06-29t15:00z" (use of lowercase time designator and
>> time zone offset). Chrome and Edge accept and transform clearly invalid
>> out-of-bounds dates like "2018-02-30", and Edge and Safari accept
>> out-of-bounds time zone offsets like "2018-06-28T15:00-24:00". And Firefox
>> rejects almost everything not matching the format exactly (although even it
>> allows partially- or over-specified fractional seconds like
>> "2018-06-29T11:00:12.3456").
>> To that end, I'd like to standardize Date.parse processing of input that
>> encompasses the Date Time String Format and its ISO 8601-like
>> neighborhood—both acceptance of the subset that is valid AND rejection of
>> the subset that is not. Details are at ecma262-proposal-uniform-in
>> terchange-date-parsing
>> <>,
>> and comments are welcome.
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list