Hello, not sure if this is the best place to post the question, but here we go: Is there a way to de...

# server

[Dominik Sandjaja]

Hello,
not sure if this is the best place to post the question, but here we go:
Is there a way to define the resolution that Kotlin uses for `Instant`s?
Reason: Our Kotlin application talks to a PostgreSQL database and saves `Instant`s in a timestamp 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]

#kotlinx-datetime might be a better place to ask

[Klitos Kyriacou]

Are you actually using kotlinx.datetime or java.time? If it's the latter, you can use

Instant.now().truncatedTo(ChronoUnit.MICROS)

[Dominik Sandjaja]

kotlinx.datetime.Instant, retrieved usually via Clock.System.now().

[Klitos Kyriacou]

This might be relevant, though not useful: https://github.com/Kotlin/kotlinx-datetime/issues/62

[Dominik Sandjaja]

Ah, thanks, that is something I will keep an eye on.

[Klitos Kyriacou]

Well, that ticket was closed with a note saying it's not the intention for kotlinx.datetime to provide all the functionality of java.time, so I don't know where we go from here. It feels disappointing and I hope the future of kotlinx.datetime improves. At present, I just use java.time.

[Sam]

Was thinking about this; what if you just make your own Clock?

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
        )
    }
}

[dmcg]

Also, you probably don’t want to be storing Instants in a timestamp column, even though it seems entirely sane. If you do, then your database and client timezones will be significant to the values that you read.

https://youtu.be/vuMN0IU4EVg▾

[Dominik Sandjaja]

Thank you both for the responses.
I see multiple aspects at play here. One is the fact that the precision is different between different operating systems. This is nothing Kotlin specific, though, and rather a limitation of our JVM <-> PostgreSQL interaction. My original intention was to have a simple workaround to unify this behavior across OSs.
The other aspect would be if we actually want and need (no) the nanoseconds. I'd rather not do workarounds just to avoid having nanoseconds ...

[Dominik Sandjaja]

@dmcg: I found that out the hard way, although this is a different issue and we handle that separately. I think I even commented on your original post of this video in #feed (?) 🙂

[dmcg]

Ah yes hello. If you want to be recognised you’re going to need a better avatar!