0

I tried Date.parse("2020-02-31");(31st Feb. 2020) and it returns 1583107200000 or new Date("2019-02-30").toISOString().substring(0, 10); returns '2019-03-02'. Why such a behaviour?

Seems like all the overflow in "DD" part till 31 seems to work even when it should not.

Something like Date.parse("2020-02-32") or Date.parse("2020-13-01") returns a NaN.

Note: I'm using Node.js and replicated in Google Chrome developer console.

Omkar
  • 402
  • 1
  • 3
  • 10
  • Why? Because it's been designed this way, I guess. My guess would be that you can only use valid numbers for months/days, otherwise you get an invalid date. But it's just a guess - I suspect any explanation here would be a guess unless somebody who designed `Date.parse` comes in to explain the design decision. Which might just be "Well, it was the easiest way to implement it back in the day, then it just stuck. – VLAZ Feb 04 '20 at 16:09
  • 1
    If you mean that the date returned is into the next month, then that is expected behaviour for dates that 'overflow' the current month. See https://flaviocopes.com/javascript-dates/ for more: "JavaScript tries hard to work fine Pay attention. If you overflow a month with the days count, there will be no error, and the date will go to the next month:" I believe that the reasoning is to make date maths easy - add seven days to the current date and you still have a valid (and _correct_ date) even at the end of the month. – MikeB Feb 04 '20 at 16:09
  • @MikeBrockington Well then why something like `Date.parse("2020-02-32")` returns a `NaN`. It is an 'overflow'. So is the month 13 to the next year. I mean clearly the date is invalid so returning anything except `NaN` kinda defects the purpose of having Date.parse. – Omkar Feb 04 '20 at 16:13
  • "Strings that are unrecognizable or contain out-of-bounds format element values shall cause Date.parse to return NaN." [spec](https://tc39.es/ecma262/#sec-date.parse), "DD is the day of the month as two decimal digits from 01 to 31." [spec](https://tc39.es/ecma262/#sec-date-time-string-format). – ASDFGerte Feb 04 '20 at 16:14
  • @Omkar it's very simple - [it's not a valid date as defined in the spec](https://tc39.es/ecma262/#sec-date-time-string-format). `32` is not allowed as a **DD** value. – VLAZ Feb 04 '20 at 16:14
  • 1
    Does this answer your question? [javascript Date.parse assumes 31 days in February and all months?](https://stackoverflow.com/questions/32284968/javascript-date-parse-assumes-31-days-in-february-and-all-months) – ASDFGerte Feb 04 '20 at 16:19
  • The last part of the answer is actually very interesting: `Date.parse("2020-02-31")` is `NaN` on e.g. FireFox. – ASDFGerte Feb 04 '20 at 16:20
  • @ASDFGerte Yup. Never actually found it when I searched. Thanks. – Omkar Feb 04 '20 at 16:22
  • @ASDFGerte eh, I honestly don't think it's that interesting. Seems to depend on the spec interpretation, since it says "*in general, the value produced by Date.parse is implementation-dependent when given any String value that does not conform to the Date Time String Format (20.4.1.15)*". So, this is definitely implementation dependant behaviour. As is *a lot* with date parsing already, so it's just the same old date shenanigans. Do̴n̸'̴t̷ l̷̩͠o̵̟͂ȍ̴͕k̷̺̕ i̵̘̓n̷̙̎t̶͚̜̃̒o̵̹̳͝͝ ̶̼́į̸͠ṫ̵͈̹ t̸̘̅̂ǫ̴̨̬̘͖̿̈́̎̕õ̷͇͈̾̅̋͌ ̶̛̤̹̫̹̭̬̓̌͂̃̓̔ͅc̵̨̢͔̗̭͈͑̈́̍͊͒̊͜͠l̴̪̭̃̊o̷͍̼͒ş̷́̅̇e̷̼̋̀͐͂͂l̵̺͚̪̬͙̺͗͑̒ͅy̶̼͓̥̿̃̐. – VLAZ Feb 04 '20 at 16:24
  • @VLAZ well, the information of "this behavior is implementation dependent, and `Date.parse("2020-02-31")` actually gives different results on various browsers" is probably interesting for OP - it means, that there is no specific rule for overflow or anything. Input an invalid date, and who knows what will happen. – ASDFGerte Feb 04 '20 at 16:28
  • @ASDFGerte exactly. Trying to find reason in the madness that is "implementation dependant" date parsing tends to lead to ruin. Of the mind mostly. – VLAZ Feb 04 '20 at 16:30

0 Answers0