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

Jordan Harband ljharb at
Fri Jun 29 20:50:04 UTC 2018

See also

On Fri, Jun 29, 2018 at 1:01 PM, Richard Gibson <richard.gibson at>

> TL;DR:
> interchange-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-
> interchange-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