Invalid Date object will throw a TypeError

[chaijs]

Invalid Date object will throw a TypeError

[dotnetCarpenter]

I think that for the sake of loupe, the right step forward is to return Invalid Date.

The specs unfortunately states that the behavior is both "may fall back to any implementation-specific heuristics or implementation-specific date formats" and "Strings that are unrecognizable shall cause Date.parse to return NaN".
This makes me think that we should return NaN since the String is "unrecognizable" but my tests shows that both V8 and SpiderMonkey agrees on "implementation-specific heuristics" for a String that is clearly not a date. It gets mucky when I use a String that has a year component in it. E.g. foo-bar 2022.

Below are my notes about the subject. I will add a simple PR which will return "Invalid Date" with a link to this issue.

From the ECMAScript® 2022 Language Specification 21.4.2.1 Date ( ...values )

When the Date function is called, the following steps are taken:

1. If NewTarget is undefined, then
   1. ...
2. Let numberOfArgs be the number of elements in values.
3. If numberOfArgs = 0, then
   1. ...
4. Else if numberOfArgs = 1, then
   1. Let value be values[0].
   2. If Type(value) is Object and value has a [[DateValue]] internal slot, then
      1. ...
   3. Else,
      1. Let v be ? ToPrimitive(value).
      2. If Type(v) is String, then
         1.Assert: The next step never returns an abrupt completion because Type(v) is String.
         1. Let tv be the result of parsing v as a date, in exactly the same manner as for the parse method (21.4.3.2).

21.4.3.2:
If the String does not conform to that format (Date Time String Format) the function may fall back to any implementation-specific heuristics or implementation-specific date formats. Strings that are unrecognizable or contain out-of-bounds format element values shall cause Date.parse to return NaN.

21.4.4.37 Date.prototype.toJSON ( key ):

Note 2

The toJSON function is intentionally generic; it does not require that its this value be a Date. Therefore, it can be transferred to other kinds of objects for use as a method. However, it does require that any such object have a toISOString method.

JS engine behavior

const d = new Date('not a date');

Method	node 18 V8	Firefox
valueOf	NaN	NaN
toString	Invalid Date	Invalid Date
toUTCString	Invalid Date	Invalid Date
toISOString	RangeError: invalid date	RangeError: invalid date
toJSON	null	null

const d = new Date('foo-bar 2022');

Method	node 18 V8	Firefox
valueOf	1640991600000	NaN
toString	Sat Jan 01 2022 00:00:00 GMT+0100 (Central European Standard Time)	Invalid Date
toUTCString	Fri, 31 Dec 2021 23:00:00 GMT	Invalid Date
toISOString	2021-12-31T23:00:00.000Z	Invalid Date
toJSON	2021-12-31T23:00:00.000Z	null

Test code:

const test = f => {
	let r;
	try {
		r = f.call(d);
	} catch (err) {
		r = err;
	}
	return r;
}

[
    Date.prototype.valueOf,
	Date.prototype.toString,
	Date.prototype.toUTCString,
	Date.prototype.toISOString,
	Date.prototype.toJSON,
].map(test)
 .forEach(m => { console.debug(m); });

[dotnetCarpenter]

I would be happy to provide a patch if I know what the return value should be for invalid dates.
I am not a direct consumer of Loupe but rather of Vitest. So for me it would make sense to return NaN, which is a global variable but that is inconsistent with the description of Loupe.

Loupe turns the object you give it into a string.

A better place to fix this might be in chai?

[dotnetCarpenter]

Ping @keithamus

[keithamus]

Thanks for the issue @dotnetCarpenter. I trust your judgement and would be happy to merge a PR. FWIW nodejs, Chrome devtools, and Firefox devtools all render this as Invalid Date.

[dotnetCarpenter]

Fixed in v2.3.5 🎉