Closed juni0r closed 1 year ago
Nice catch. We should be using value.equals(originalValue)
here. Can you please send a PR for the same?
Upon closer inspection I realized that DateTime's concept of equality is … well … eccentric
Two DateTimes are equal iff they represent the same millisecond, have the same zone and location, and are both valid. To compare just the millisecond values, use +dt1 === +dt2.
I don't want to argue with this, but in my view a date represents a moment in time which is the same, no matter if you're in India, Germany or on the Moon. I just think you should be aware since there might be other parts of the codebase where this becomes an issue.
In terms of an ORM I believe it's the most sensible choice to consider two dates equal if their timestamp is equal, hence valueOf()
which is precisely what fast-deep-equal uses. So that would boil down to this:
- if (DateTime.isDateTime(value) || DateTime.isDateTime(originalValue)) {
- isEqual = value === originalValue
- } else if (isObject(value) && 'isDirty' in value) {
+ if (isObject(value) && 'isDirty' in value) {
isEqual = !value.isDirty
} else {
isEqual = equal(originalValue, value)
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Two DateTime values that represent the same time in different time zones aren't considered equal by
BaseModel.$isDirty
. It uses===
to compare DateTime values which is not the proper semantics since bothequals()
as well as strict equality===
for the respectivevalueOf()
two DateTimes would betrue
:https://github.com/adonisjs/lucid/blob/98644992cbd55cd1fdaa4b1fcf40d38540440083/src/Orm/BaseModel/index.ts#L1244-L1253