You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Looking at the implementation in IEquiv, it seems the behaviour is conditional on the types (in the example above, (instance? goog.date.UtcDateTime other) on L51 would return false), whereas cljs-time.core/= coerces everything to a timestamp and compares that.
Is this intentional?
The text was updated successfully, but these errors were encountered:
I don't remember the exact reason that IEquiv ended up checking for exact types, it didn't start out that way (see c0c43b8). But I do remember some weirdness around
The fact that the functionality is different is not intentional, most likely I forgot cljs-time.core/= even existed. I'd have removed cljs-time.core/= a long time ago, but people were using it.
Not sure that a subtle behaviour change at this point is a great idea though.
Hi, thanks for all the work done on this excellent library!
I'm wondering if there's a reason that the
Equiv
implementation incljs-time.extend
andcljs-time.core/=
return different results?Looking at the implementation in
IEquiv
, it seems the behaviour is conditional on the types (in the example above,(instance? goog.date.UtcDateTime other)
on L51 would returnfalse
), whereascljs-time.core/=
coerces everything to a timestamp and compares that.Is this intentional?
The text was updated successfully, but these errors were encountered: