Test issue: JDBCTimeZoneZonedTest

[Sanne]

This failed today with error:

java.util.concurrent.CompletionException: org.opentest4j.AssertionFailedError: 
expected: 2023-08-03T09:50:51.570Z
 but was: 2023-08-03T09:50:51.569999Z
when comparing values using Comparator$$Lambda$251/0x00000008010d4808
	at java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:315)
	at java.base/java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:320)

The actual value is extremely close to the expectation, seems like a problem of lack of precision during conversions, most likely unavoidable? Perhaps all we need is to allow some margin of error.

[relentless-pursuit]

I was able to reproduce the issue.

org.opentest4j.AssertionFailedError: [Comparing nanoseconds of z.zonedDateTime with z.offsetDateTime] 
expected: 120643000
 but was: 120618000
java.util.concurrent.CompletionException: org.opentest4j.AssertionFailedError: [Comparing nanoseconds of z.zonedDateTime with z.offsetDateTime] 
expected: 120643000
 but was: 120618000

I made comparison between the nanosecond part of z.zonedDateTime and nanosecond part of z.offsetDateTime. But, I was able to reproduce the issue with a custom unit test method. I didn't get any assertion failure while running the test method of JDBCTimeZoneZonedTest.

[relentless-pursuit]

Also, we are already using roundToDefaultPrecision. I assume it should take care of some fractional difference. But, if not, shall i proceed with creating a custom rounding logic?

[DavideD]

I haven't checked the code, but rounding to the default precision makes sense to me. I would avoid custom logic.

[DavideD]

The same issue also happens from time to time with ColumnZonedTest.

But we already truncate and use roundToDefaultPrecision. I will try to have a better look when I have time