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 <[email protected]> wrote: > See also https://github.com/tc39-transfer/proposal-date-time-string-format > > On Fri, Jun 29, 2018 at 1:01 PM, Richard Gibson <[email protected]> > wrote: > >> TL;DR: https://github.com/gibson042/ecma262-proposal-uniform-interc >> 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 >> <https://github.com/gibson042/ecma262-proposal-uniform-interchange-date-parsing>, >> and comments are welcome. >> >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> >> >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
