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

[Richard Gibson]

TL;DR:
https://github.com/gibson042/ecma262-proposal-uniform-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
<https://github.com/gibson042/ecma262-proposal-uniform-interchange-date-parsing>,
and comments are welcome.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180629/d65d9c85/attachment.html>