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.

public class Demo {
    @Test
    void compareSqlTimestampWithInstant() {
        final long now = System.currentTimeMillis();
        final Timestamp ts = new Timestamp(now);
        final Instant instant = Instant.ofEpochMilli(now);
        assertEquals(ts.getNanos(), instant.getNano()); // this succeeds
        assertThat(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().