java.time.Instant argument saving and loading on JDK 21 seems to be different on macOS vs Ubuntu

[vinaysshenoy]

I am running into a weird issue once I upgraded my Kotlin/JVM project to JDK 21. For more information, here is what my project stack looks like:

• Kotlin: 1.9.20
• JDBI version: 3.38.2
• Database: Postgres 14.7 (using Testcontainers for my integration tests)
• OS: macOS for local development/Ubuntu in CI
• JDK version: 21 (Temurin)
• Gradle: 8.5

Some of my tests started failing only on CI (they pass on my local development MacBook). After digging into the tests, it seems specifically that java.time.Instant objects are being saved and loaded with a different precision than what the system timestamp generates. You can see this with the following log statement:

Original: TeacherClass(id=caf42b4e-b651-4cea-bc27-6d19dfc4eefa, userId=2877b44f-21c1-461d-b405-35038adfac40, classCode=ASD123, name=Grade A, timestamps=Timestamps(createdAt=2024-01-05T05:27:49.873493302Z, updatedAt=2024-01-05T05:27:49.873493302Z)), 
Migrated: TeacherClass(id=caf42b4e-b651-4cea-bc27-6d19dfc4eefa, userId=2877b44f-21c1-461d-b405-35038adfac40, classCode=ASD123, name=Grade A, timestamps=Timestamps(createdAt=2024-01-05T05:27:49.873493Z, updatedAt=2024-01-05T05:27:49.873493Z))

The Original object is the version of the object before it was saved to the database and the Migrated version was loaded from the database. The timestamps do not seem to have a different precision when I run them on my local development machine:

Original: TeacherClass(id=b73685ce-5f25-43d8-bd55-45b4a5fe556a, userId=72c83c23-e9ac-4b84-91c9-c53a0b0a12cd, classCode=ASD123, name=Grade A, timestamps=Timestamps(createdAt=2024-01-05T05:17:12.378779Z, updatedAt=2024-01-05T05:17:12.378779Z)), 
Migrated: TeacherClass(id=b73685ce-5f25-43d8-bd55-45b4a5fe556a, userId=72c83c23-e9ac-4b84-91c9-c53a0b0a12cd, classCode=ASD123, name=Grade A, timestamps=Timestamps(createdAt=2024-01-05T05:17:12.378779Z, updatedAt=2024-01-05T05:17:12.378779Z))

I do have a column mapper installed to map java.sql.Timestamp objects to Instant types, but it is pretty standard:

class MapTimestampToInstant: ColumnMapper<Instant> {

    override fun map(r: ResultSet?, columnNumber: Int, ctx: StatementContext?): Instant? {
        return r?.getTimestamp(columnNumber)?.toInstant()
    }
}

This works perfectly well on macOS and only fails on Linux machines. Has someone else run into a similar issue? Is there anything I can do to resolve this without rewriting my tests to not compare java.time.Instant objects directly?

[vinaysshenoy]

Seems like the issue was related to this: https://stackoverflow.com/questions/52029920/localdatetime-now-has-different-levels-of-precision-on-windows-and-mac-machine

Not sure why this specifically started happening right now, though, since I was previously on JDK 17 which should have been using the system clock precision and run into the same issues. For now, I created a fixed precision clock to use in tests to generate timestamps:

val wallClock by lazy(LazyThreadSafetyMode.SYNCHRONIZED) {
  Clock.tickMillis(ZoneOffset.UTC)
}

Closing this for now since it was not related to JDBI. But if anyone has any idea why this happened specifically with the change to JDK 21, would love to hear it.

[stevenschlansker]

Yes, we ran into multiple problems with extra clock precision too.
In addition to different systems supporting different precision, your database may also limit precision: in our case, one vendor would truncate instants and another would round, so 1.234567 would be 1.234 vs 1.235 depending on which db vendor you use.

Our solution was to truncate all timestamps to millis.

But as you say, this isn't a Jdbi problem.