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

Richard Gibson richard.gibson at gmail.com
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 gmail.com> wrote:

> See also https://github.com/tc39-transfer/proposal-date-time-string-format
>
> On Fri, Jun 29, 2018 at 1:01 PM, Richard Gibson <richard.gibson at gmail.com>
> 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
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180629/390de589/attachment-0001.html>


More information about the es-discuss mailing list