Strict equal not working with Temporal dates

[AndreVelde]

Describe the bug

Currently when the dates are not the same when using Temporal dates which I added based on the temporal-polyfill it will return that the dates are the same when using toStrictEqual on a object. Not sure if I am doing something wrong or if there is a issue.

Reproduction

Test:

it('should fail on different instant dates', () => {
  const date = Temporal.Now.instant();

  const object1 = {
      id: '123',
      lastUpdated: date,
  };
  const object2 = {
      id: '123',
      lastUpdated: date.add({ minutes: 30 }),
  };

  // This now passes when removing not
  expect(object1).not.toStrictEqual(object2);
});

it('should fail on different zoned dates', () => {
    const date = Temporal.Now.zonedDateTimeISO('UTC');

    const object1 = {
        id: '123',
        lastUpdated: date,
    };
    const object2 = {
        id: '123',
        lastUpdated: date.add({ days: 1 }),
    };

   // This now passes when removing not
    expect(object1).not.toStrictEqual(object2);
});

Package.json:

"dependencies": {
   "temporal-polyfill": "0.3.0"
},

System Info

System:
    OS: Windows 11 10.0.22631
    CPU: (16) x64 11th Gen Intel(R) Core(TM) i7-11800H @ 2.30GHz
    Memory: 12.81 GB / 63.73 GB
  Binaries:
    Node: 22.13.0 - C:\Program Files\nodejs\node.EXE
    npm: 11.3.0 - C:\Program Files\nodejs\npm.CMD
  Browsers:
    Edge: Chromium (130.0.2849.80)
    Internet Explorer: 11.0.22621.3527
  npmPackages:
    @vitest/coverage-istanbul: ^3.1.3 => 3.1.3
    @vitest/eslint-plugin: ^1.2.0 => 1.2.0
    @vitest/spy: ^3.1.3 => 3.1.3
    vitest: ~3.1.3 => 3.1.3

Used Package Manager

npm

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
• The provided reproduction is a minimal reproducible example of the bug.

[hi-ogawa]

This is because Temporal object (at least the one from the polyfill) doesn't provide any enumerable properties, so toEqual/toStrictEqual essentially sees them as an empty object {}. (Also note that "strict" here doesn't mean object identity equality, but it only affects undefined key/value handling and a few minor difference.)

Until Temporal is widely used and testing equality is expected to work in a well-defined way (which I'm not sure what is the case right now), you can use custom equality tester to define Temporal equality https://vitest.dev/api/expect.html#expect-addequalitytesters

Here is an updated repro https://stackblitz.com/edit/vitest-dev-vitest-qc47mley?file=test%2Frepro.test.ts

import { it, expect } from 'vitest';
import { Temporal } from 'temporal-polyfill';

expect.addEqualityTesters([
  function temporalEquality(a, b) {
    const ainst = a instanceof Temporal.Instant;
    const binst = b instanceof Temporal.Instant;
    if (ainst && binst) {
      return a.toJSON() === b.toJSON();
    }
    return ainst !== binst ? false : undefined;
  },
]);

it('should fail on different instant dates', () => {
  const date = Temporal.Now.instant();
  expect(date).toEqual(date.add({ minutes: 30 }));
//  FAIL  test/repro.test.ts > should fail on different instant dates
// AssertionError: expected Temporal.Instant{} to deeply equal Temporal.Instant{}
// 
// - Expected
// + Received
// 
// - "2025-05-17T04:37:21.676Z"
// + "2025-05-17T04:07:21.676Z"
});

I think we need to eventually handle this as a builtin equality just like Date, so it makes sense to keep this open.

[dirkluijk]

👍 +1 for a custom equality tester for Temporal!

I think there is even a way to make it work with different polyfill implementations. All Temporal types have a distinct Symbol.toStringTag, meaning Object.prototype.toString.call(obj) would return "[object Temporal.PlainDate]", etc.

Object.prototype.toString.call(1); // [object Number]
Object.prototype.toString.call("foo"); // [object String]
Object.prototype.toString.call(Temporal.Duration.from({ weeks: 1 })); // [object Temporal.Duration]
Object.prototype.toString.call(Temporal.Now.instant()); // [object Temporal.Instant]

Note that it might also be safe to compare the .toString() of Temporal objects. So a generic solution could be:

function isTemporalObject(obj: unknown): boolean {
  return Object.prototype.toString.call(obj).startsWith("[object Temporal.");
}

expect.addEqualityTesters([
  function temporalEquality(a, b) {
    const isATemporal = isTemporalObject(a);
    const isBTemporal = isTemporalObject(b);
    if (isATemporal && isBTemporal) {
      return a.toString() === b.toString();
    } else if (!isATemporal && !isBTemporal) {
      return undefined;
    } else {
      return false;
    }
  },
]);

Would be nice to have this, since Temporal is already being implemented in several runtimes and on its way to stage 4. :)

[hi-ogawa]

I think having this supported as builtin while this is stage 3 is okay. I'm not familiar with the desired equality semantics of temporal, but if someone has ideas, contributions are welcome.

We have basic equality logic around here and probably we can just add a few more to cover [object Temporal.xxx]

vitest/packages/expect/src/jest-utils.ts

Lines 151 to 161 in bc69ca3

	case '[object Date]': {
	const numA = +a
	const numB = +b
	// Coerce dates to numeric primitive values. Dates are compared by their
	// millisecond representations. Note that invalid dates with millisecond representations
	// of `NaN` are equivalent.
	return numA === numB || (Number.isNaN(numA) && Number.isNaN(numB))
	}
	// RegExps are compared by their source patterns and flags.
	case '[object RegExp]':
	return a.source === b.source && a.flags === b.flags

---

Another thing worth checking is the behavior on other test framework (e.g. Jest) and also Node's assert.deepStrictEqual as they might have already did something for temporal.

[dirkluijk]

Awesome! Will make an attempt to submit a PR for this soon. 😁

[dirkluijk]

All right, had a look around in the Node.js source project. Turns out, it's not yet implemented as it's still being discussed in this issue.

In that post, @LiviaMedeiros makes a good point:

Generic support from util/assert is out of scope of this issue exactly because there's no questioning that this is necessary and essential. Things like "assert.deepStrictEqual() passes for completely different Temporal.Instants" (which is currently the case with --harmony-temporal) or "util.inspect(instantInstance) doesn't really inspect its internal datetime value" would be more of a bug once Temporal graduates from experimental state.

Specific details that are facing userspace, for example:

assert.deepStrictEqual( // should this pass or throw?
  Temporal.ZonedDateTime.from('2025-04-16T20:00+09:00[Asia/Tokyo]'),
  Temporal.ZonedDateTime.from('2025-04-16T12:00+01:00[Europe/Berlin]')
);
assert.deepEqual( // should this pass or throw?
  Temporal.ZonedDateTime.from('2025-04-16T20:00+09:00[Asia/Tokyo]'),
  Temporal.ZonedDateTime.from('2025-04-16T12:00+01:00[Europe/Berlin]')
);
assert.deepEqual( // or maybe even this is somehow a good idea?
  Temporal.Instant.fromEpochMilliseconds(1234567890e3),
  new Date(1234567890e3)
);

...can be discussed, of course.

(...)

Originally posted by @LiviaMedeiros in #57891

I do have some ideas around this, and would like to participate in that discussion instead as it's a big ecosystem.

[hi-ogawa]

We normally want to align with NodeJs, but I don't think this is need to be blocked by that. For temporal use case, I think the whole point is that Temporal.ZonedDateTime should be aware of timezone in the date itself and users wish comparison to take into that account, so first two examples should fail.

For the 3rd one comparing Temporal.Instant.fromEpochMilliseconds(...) and new Date(...), that should also fail because of the general rule of deepEqual/deepStrictEqual https://nodejs.org/docs/v22.15.1/api/assert.html#assertdeepstrictequalactual-expected-message namely "type tags of objects should be the same."

I'm expecting the choice here is not too controversial though I don't know the exact temporal API allowing such comparison (for example, is toString() sufficient or should it use equals methods from each class like https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Temporal/ZonedDateTime/equals?)

[dirkluijk]

I totally agree. Every Temporal type should match all its relevant "components". So if you want more lenient comparison, e.g. for ZonedDateTime have the same instant but ignore different time zones, we can always add some custom matchers.