Dominik Sandjaja
06/09/2023, 8:14 AMtimestamp
column.
PostgreSQL has microsecond resolution for that column.
On MacOS, this works because Clock.System.now()
also returns an Instant
with microsecond resolution, so comparing an object before persisting it and after retrieving it from the database works.
On Linux (which we use for our pipeline) this same comparison fails because 2023-06-09T07:34:27.965341799Z != 2023-06-09T07:34:27.965342Z
I found similar issues for e.g. H2, but there it seems possible to simply store nanoseconds in the database.
It is not necessarily an issue to change the tests, we can simply set fixed instants (without nanosecond precision), but the question remains nevertheless:
Is there a way to force Kotlin to always use a specific precision?Sam
06/09/2023, 8:18 AMKlitos Kyriacou
06/09/2023, 9:25 AMInstant.now().truncatedTo(ChronoUnit.MICROS)
Dominik Sandjaja
06/09/2023, 9:25 AMkotlinx.datetime.Instant
, retrieved usually via Clock.System.now()
.Klitos Kyriacou
06/09/2023, 9:28 AMDominik Sandjaja
06/09/2023, 9:32 AMKlitos Kyriacou
06/09/2023, 9:38 AMSam
06/09/2023, 9:47 AMClock
?
object SystemClockMicros: Clock {
override fun now(): Instant {
val now = Clock.System.now()
val micro = now.nanosecondsOfSecond / 1000
return Instant.fromEpochSeconds(
epochSeconds = now.epochSeconds,
nanosecondAdjustment = micro * 1000
)
}
}
Dominik Sandjaja
06/09/2023, 10:03 AMDominik Sandjaja
06/09/2023, 10:07 AMdmcg
06/09/2023, 10:29 AM