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

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

# Richard Gibson (6 years ago)

TL;DR: 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 gibson042/ecma262-proposal-uniform-interchange-date-parsing,

and comments are welcome.

# Jordan Harband (6 years ago)

See also tc39-transfer/proposal

# Richard Gibson (6 years ago)

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.