the new Date() constructor is an amalgamation of like 5 different specs, and unless the input matches one of them, which one kicks in is up to the implementer's choice
I think NaN itself is a bit of an error object, especially in how it's passed through subsequent math functions, which is a different choice than throwing up.
But besides that I think you're right, Invalid Date is pretty weird and I somehow never ran into it.
One consequence is you can still call Date methods on the invalid date object and then you get NaN from the numeric results.
Guessed 2 of the first 3 questions.
Got to question 4 and gave up:
There's literally no way of guessing this crap. It's all random.
I had no idea we even had an `Invalid Date` object, that's legitimately insane. Some other fun ones:
are both valid dates lol.
the new Date() constructor is an amalgamation of like 5 different specs, and unless the input matches one of them, which one kicks in is up to the implementer's choice
The choice here is really surprising. I was half-expecting NaN, that you omitted.
Is there any other instance of the standard JS library returning an error object instead of throwing one? I can't think of any.
I think NaN itself is a bit of an error object, especially in how it's passed through subsequent math functions, which is a different choice than throwing up.
But besides that I think you're right, Invalid Date is pretty weird and I somehow never ran into it.
One consequence is you can still call Date methods on the invalid date object and then you get NaN from the numeric results.
The fun trick is that Invalid Date is still a Date:
You were half-correct on expecting NaN, it's the low level storage of Invalid Date:
Invalid Date is just a Date with the "Unix epoch timestamp" of NaN. It also follows NaN comparison logic:
It's an interesting curio directly related to NaN.
1 reply →