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
Describe the bug
A clear and concise description of what the bug is.
assertj core version: 3.25.3
java version: 21.0.1-open
test framework version: JUnit 5.10.2
os (if relevant): Linux 6.5.0-15-generic # 15-Ubuntu SMP PREEMPT_DYNAMIC Tue Jan 9 17:03:36 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux (Ubuntu 23.10)
Test case reproducing the bug
Some timestamp types, for example, java.sql.Timestamp, are not specifically handled when comparing with other temporal types, and as a result, though there are no compile-time errors caused by types, they are not effectively compared as temporals.
publicclassDemo {
@TestvoidcompareSqlTimestampWithInstant() {
finallongnow = System.currentTimeMillis();
finalTimestampts = newTimestamp(now);
finalInstantinstant = Instant.ofEpochMilli(now);
assertEquals(ts.getNanos(), instant.getNano()); // this succeedsassertThat(ts).isEqualTo(instant); // this fails.assertThat(ts).isAfterOrEqualTo(instant); // even if I want to relax the check, this still fails
}
}
I can see there are javadocs mentioning that comparisons are done by converting these timestamp types to java.util.Date, but is there a way to make this less surprising, otherwise make it a compilation error, so the user can take care of nanoseconds?
Updated: I thought it was caused by nano-second precision being dropped along the assertion classes, but it turns out that there is no special handling of such types, and they end up calling Object.equals().
The text was updated successfully, but these errors were encountered:
IUSR
changed the title
Nanoseconds dropped when comparing types that support nanosecond precision
Unable to compare some timestamp types
Feb 7, 2024
Thanks for confirming, Stefano! Yes, I am currently converting the timestamp/temporal objects into the same type and comparing them as a workaround. It'd be good when things "just work", as my experience with assertj has been :)
Describe the bug
A clear and concise description of what the bug is.
Test case reproducing the bug
Some timestamp types, for example,
java.sql.Timestamp
, are not specifically handled when comparing with other temporal types, and as a result, though there are no compile-time errors caused by types, they are not effectively compared as temporals.I can see there are javadocs mentioning that comparisons are done by converting these timestamp types to
java.util.Date
, but is there a way to make this less surprising, otherwise make it a compilation error, so the user can take care of nanoseconds?Updated: I thought it was caused by nano-second precision being dropped along the assertion classes, but it turns out that there is no special handling of such types, and they end up calling
Object.equals()
.The text was updated successfully, but these errors were encountered: