How do people deal with writing test that involve ...

# exposed

[Romain]

How do people deal with writing test that involve time and database? I'm storing a LocalDateTime in a postgres table. It works locally, but in CI it fails with this kind of error:

"updatedAt" expected: <2026-04-14T23:54:34.282592497>, but was: <2026-04-14T23:54:34.282592>

Not sure if I should solve this at exposed's level or at the test one. Any idea?

[Goetz Markgraf]

There are databases that can not store nano but store millis. So when you save the TS with nanos, it gets truncated. In this case it has nothing to do with exposed but with the database or the db configuration.

[Fredrik Tõnisson-Bystam]

We had this problem a lot when we bumped to Java17, because I think they increased the precision of Instant and friends somewhere around there in the JDK. But as Goetz said, Postgres only does millis.

We solved it in one of two ways:
• Make both expected and actual values somehow make a round-trip through the DB to have them both truncated
• Start using assertion functions that does some kind of isCloseTo comparison instead

[phldavies]

Most of our tests use a Clock instance to control time, and we have a MicrosecondTruncatedClock wrapper that truncates all instants to microseconds (as supported by Postgres)

[Romain]

Oh that's a good idea!

[Jaap Beetstra]

On JVM there are standard API calls for truncated clocks, e.g. Clock.tick and Clock.tickMillis