'2012-12-12' < '2013-11-12' // true
Compares the dates as strings. One benefit of ISO 8601 formatting is that timestamps compare correctly as strings provided the offset (if there is one) is the same. E.g.
'2022-01-06T09:00:00+10:00' < '2022-01-06T00:00:00Z'
should be true, but it returns false, whereas:
new Date('2022-01-06T09:00:00+10:00') < new Date('2022-01-06T00:00:00Z')
returns true (see below for why). But comparing other date formats as strings almost certainly won't work, e.g. using d/m/y format:
01/03/2020 < 01/02/2021
returns false because the "3" in "03" is greater than the "2" in "02" and that's as far as the comparison gets.
Then there is:
new Date('2012-12-12') < new Date('2013-11-12') // true
which works because both timestamps are parsed as UTC to produce a time value (a number value that is the date's offset from 1 Jan 1970 in milliseconds). The <
operator coerces the Date objects to primitives which, in this case, effectively calls valueOf which returns the time value, hence the comparison is reduced to:
1355270400000 < 1384214400000
That's why strings are often parsed to Date objects for comparison. Note however that while:
'2022-01-06' == '2022-01-06' // true
When converted to Dates:
new Date('2022-01-06') == new Date('2022-01-06') // false
because two objects (Date or other) are never ==
or ===
to each other, so:
new Date(/* anything */) == new Date(/* anything */)
is always false, even if both Date objects represent invalid dates. If you want to see if they're equal, compare the time values:
new Date('2022-01-06').getTime() == new Date('2022-01-06').getTime()
But be careful when parsing strings, see Why does Date.parse give incorrect results?