JP22: "20.3.1.16 Date Time String Format" is not clear for "2000-02-31", "2015-01-01T24:59:00"

[akr]

The description "20.3.1.16 Date Time String Format" is not clear that "2000-02-31" and "2015-01-01T24:59:00" are valid or not.

The spec defines validity as follows:
Illegal values (out-of-bounds as well as syntax errors) in a format string means that the format string is not a valid instance of this format.

Each component of 2000-02-31 and 2015-01-01T24:59:00 is not out-of-bounds.
But combination of them, Feb 31 and 24:59, can be considered as out-of-bounds.

[anba]

"out-of-bounds" is supposed to refer to invalid date-time values like Feb 31:

"2000-02-32" is rejected because it's not valid syntax (the DD field ranges from 01 to 31), whereas "2000-02-31" is rejected because the values are out-of-bounds.

Additional notes to clarify the term "out-of-bounds" could be added to the spec.

[anba]

"out-of-bounds" is supposed to refer to invalid date-time values like Feb 31:

"2000-02-32" is rejected because it's not valid syntax (the DD field ranges from 01 to 31), whereas "2000-02-31" is rejected because the values are out-of-bounds.

Additional notes to clarify the term "out-of-bounds" could be added to the spec.

[hueitan]

According to the browser running in chrome. Here's the result.

It's already "out-of-bounds" but it will auto shift to 2 Mar. It should be the "syntax errors"

Well, this get no errors too.

[hueitan]

According to the browser running in chrome. Here's the result.

It's already "out-of-bounds" but it will auto shift to 2 Mar. It should be the "syntax errors"

Well, this get no errors too.

[claudepache]

According to 20.3.3.2, the result is implementation-dependent when "the String does not conform to the Date Time String Format", which means to me that the interpretation of "2000-02-31" is left to the discretion of the implementation.

[claudepache]

According to 20.3.3.2, the result is implementation-dependent when "the String does not conform to the Date Time String Format", which means to me that the interpretation of "2000-02-31" is left to the discretion of the implementation.

[hueitan]

I agree with that, thanks @claudepache
Therefore, every vendor can have their own implementation.

In my experience,

// chrome
var d1 = new Date('2014-10-01T07:19:33.657'); // toISOString => 2014-10-01T07:19:33.657Z

// firefox
var d2 = new Date('2014-10-01T07:19:33.657'); // toISOString => 2014-09-30T23:19:33.657Z (wat!)

We are getting the different results from vendors, it follows 20.3.3.2 implementation-dependent.

It's unpredictable, omg 😱

[hueitan]

I agree with that, thanks @claudepache
Therefore, every vendor can have their own implementation.

In my experience,

// chrome
var d1 = new Date('2014-10-01T07:19:33.657'); // toISOString => 2014-10-01T07:19:33.657Z

// firefox
var d2 = new Date('2014-10-01T07:19:33.657'); // toISOString => 2014-09-30T23:19:33.657Z (wat!)

We are getting the different results from vendors, it follows 20.3.3.2 implementation-dependent.

It's unpredictable, omg 😱

[anba]

That difference between Chrome and Firefox is caused by #87.

[anba]

That difference between Chrome and Firefox is caused by #87.

[hueitan]

Thank you for the link @anba 🙇

[hueitan]

Thank you for the link @anba 🙇

[allenwb]

It was never the intent that the addition of ISO date parsing would add additional implementation differences when parsing strings into dates. We shouldn't have used language that allows syntactically valid ISO dates containing "out-of-bounds" subfields to fall back to an implementation defined meaning.

So, in 2.3.3.2:

If the String does not conform to that format the function may fall back to any implementation-specific heuristics or implementation-specific date formats.

should be replaced with:

If the String does not conform to the Date Time String Format (20.3.1.16) syntax the function may fall back to any implementation-specific heuristics or implementation-specific date formats.

Plus perhaps add a note:

NOTE Strings that confirm to the Date Time String Format (20.3.1.16) syntax but contain out-of-bound values do not fall back to an implementation defined interpretation.

[allenwb]

It was never the intent that the addition of ISO date parsing would add additional implementation differences when parsing strings into dates. We shouldn't have used language that allows syntactically valid ISO dates containing "out-of-bounds" subfields to fall back to an implementation defined meaning.

So, in 2.3.3.2:

If the String does not conform to that format the function may fall back to any implementation-specific heuristics or implementation-specific date formats.

should be replaced with:

If the String does not conform to the Date Time String Format (20.3.1.16) syntax the function may fall back to any implementation-specific heuristics or implementation-specific date formats.

Plus perhaps add a note:

NOTE Strings that confirm to the Date Time String Format (20.3.1.16) syntax but contain out-of-bound values do not fall back to an implementation defined interpretation.

[bterlson]

It's a shame we've apparently ceded control to implementations. And they now differ: spidermonkey throws an exception for out-of-bounds dates, Edge and Chrome don't.

@allenwb assuming we use some version of your text, it isn't exactly obvious what the behavior of out-of-bounds date values is specified to be. It makes sense that it would be the same behavior as constructing a date, passing the parsed field values for their corresponding parameters, but seems like we should say that somehow? Maybe I'm missing something.

[bterlson]

It's a shame we've apparently ceded control to implementations. And they now differ: spidermonkey throws an exception for out-of-bounds dates, Edge and Chrome don't.

@allenwb assuming we use some version of your text, it isn't exactly obvious what the behavior of out-of-bounds date values is specified to be. It makes sense that it would be the same behavior as constructing a date, passing the parsed field values for their corresponding parameters, but seems like we should say that somehow? Maybe I'm missing something.

[bterlson]

talked with @anba on IRC and have won the following understanding:

• The impact of @allenwb's change is that Date.parse of an out-of-bounds date form should return NaN.
• Chrome and Edge presently parse these patterns fine.

Given that there isn't an implementation consensus (and that it's possible Chrome and Edge users could be broken by this change) I wonder if we should instead specify the Chrome/Edge behavior instead (as presumably FF and JSC could begin parsing previously invalid dates with less risk). Thoughts?

[bterlson]

talked with @anba on IRC and have won the following understanding:

• The impact of @allenwb's change is that Date.parse of an out-of-bounds date form should return NaN.
• Chrome and Edge presently parse these patterns fine.

Given that there isn't an implementation consensus (and that it's possible Chrome and Edge users could be broken by this change) I wonder if we should instead specify the Chrome/Edge behavior instead (as presumably FF and JSC could begin parsing previously invalid dates with less risk). Thoughts?

[claudepache]

For me, an invalid input is better served with an error condition (specifically, NaN / Invalid Date) than an bogus result. Note that we are speaking of a date-time format where validity is, I think, well defined.

Also, it is not clear why "2000-02-31" should be interpreted as "two days after 2000-02-29" (it could have been: "last day of Feb 2000"), and why "2000-02-32" should be rejected.

[claudepache]

For me, an invalid input is better served with an error condition (specifically, NaN / Invalid Date) than an bogus result. Note that we are speaking of a date-time format where validity is, I think, well defined.

Also, it is not clear why "2000-02-31" should be interpreted as "two days after 2000-02-29" (it could have been: "last day of Feb 2000"), and why "2000-02-32" should be rejected.

[RobG000]

It seems to me that the obvious solution is to introduce a new Date.parseISO method that parses a string as if it was an ISO 8601 compliant string. That "breaks" nothing and is consistent with toISOString and the UTC methods (getUTCHours, etc.) and how getYear was fixed with getFullYear.

It also means implementations can continue with their implementation–dependent behaviour for Date.parse and those who wish to have a standardised parser have one bulit–in. Parsing and validating an ISO 8601 format string is trivial, it takes just 4 lines of standard ECMAScript. It's staggering that ECMAScript has got this far with such a rubbish date parser.

Can we please have some common sense on this issue?

[RobG000]

It seems to me that the obvious solution is to introduce a new Date.parseISO method that parses a string as if it was an ISO 8601 compliant string. That "breaks" nothing and is consistent with toISOString and the UTC methods (getUTCHours, etc.) and how getYear was fixed with getFullYear.

It also means implementations can continue with their implementation–dependent behaviour for Date.parse and those who wish to have a standardised parser have one bulit–in. Parsing and validating an ISO 8601 format string is trivial, it takes just 4 lines of standard ECMAScript. It's staggering that ECMAScript has got this far with such a rubbish date parser.

Can we please have some common sense on this issue?