feat: initial support for Temporal equality - #8007
sheremet-va merged 3 commits into
Conversation
Sorry, something went wrong.
✅ Deploy Preview for vitest-dev ready!Built without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify project configuration. |
Sorry, something went wrong.
| case '[object Temporal.PlainYearMonth]': | ||
| case '[object Temporal.PlainMonthDay]': | ||
| case '[object Temporal.Duration]': | ||
| return a.toString() === b.toString() |
There was a problem hiding this comment.
Do you know which is preferred whether toString equality and builtin equals method? https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Temporal/ZonedDateTime/equals
It looks like there are several old issues mentions calendar comparison (such as tc39/proposal-temporal#625), but the discussion seem quite technical 😅
Sorry, something went wrong.
There was a problem hiding this comment.
.equals() seems to compare including the calendar, so I think it's a good suggestion. Let's do it!
For Temporal.Duration this .equals() method doesn't exist, but I wasn't sure about that one to begin with. For Durations, there IS actually ambiguity. For example, are 60 seconds and 1 minute the same? If you compare the duration in time, yes; but if you literally compare all their components, no. Also, for example "1 day" is not necessarily the same as "24 hour" and depends on context.
My suggestion is to use .toString() for durations so it does a literal comparison of all the different components.
Sorry, something went wrong.
There was a problem hiding this comment.
Indeed it looks like Duration is tricky. tc39/proposal-temporal#856 seems to explain the details.
As a builtin equality, I think choosing toString comparison makes sense since that's the most strict way to do it. Users can still add own custom equality tester to loosen it if desired.
Sorry, something went wrong.
|
@hi-ogawa I updated the PR:
|
Sorry, something went wrong.
hi-ogawa
left a comment
There was a problem hiding this comment.
Thanks!
Sorry, something went wrong.
|
I'm one of the champions of the Temporal proposal. Sorry I was too late to comment on this PR back in May, but I was very happy to see this PR! Thanks for building it. I did have a question for @hi-ogawa and @dirkluijk: in vitest, is equality comparison expected to have no observable differences between the values? If yes, then using Temporal.ZonedDateTime.prototype.equals might be a problem. Two ZonedDateTime instances can use time zone IDs that are aliases of each other in the IANA Time Zone Database, for example Asia/Calcutta and Asia/Kolkata. The equals method will canonicalize the time zone ID before comparing, so those two time zones (and hence the ZDT instances) will be considered equal. But the value of the timeZoneId property on the ZDT instances will be different. That said, this may be desirable behavior. One of the main reasons that we made equals canonicalize time zones is to avoid breaking automated tests when a time zone ID is deprecated in favor of a new name, like the recent rename of Europe/Kiev => Europe/Kyiv. If you use equals, then you're guaranteed that even if the IANA Time Zone Database changes, your tests will still behave the same. So the behavior in this PR may be better! But at least I wanted to flag the behavior in case you didn't want it. |
Sorry, something went wrong.
@justingrant Thanks for the heads up! For this case, Vitest's goal is to provide whatever most ergonomic for users and we don't necessary need to detect anything observable. Since Temporal provides one "opinionated" equality implementation, I think test/assertion framework building up on it sounds most natural. For any niche use case, Vitest allows overriding equality via addEqualityTesters, which can always serve as escape hatch. |
Sorry, something went wrong.
Description
Fixes #7991
Please don't delete this checklist! Before submitting the PR, please make sure you do the following:
Tests
Documentation
Changesets