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:

    > let invalid = new Date('not a date')
    > invalid
    Invalid Date
    > invalid instanceof Date
    true

You were half-correct on expecting NaN, it's the low level storage of Invalid Date:

    > invalid.getTime()
    NaN

Invalid Date is just a Date with the "Unix epoch timestamp" of NaN. It also follows NaN comparison logic:

    > invalid === new Date(NaN)
    false

It's an interesting curio directly related to NaN.

> Invalid Date is just a Date with the "Unix epoch timestamp" of NaN. It also follows NaN comparison logic: > > > invalid === new Date(NaN) > false

This is just because a JS Date is an object and have nothing to do with the inner representation.

    > new Date(0) === new Date(0)
    false