`Instant` support Chrono fields

[chrisjenx]

Most other date packages support setting the fields of each time unit on something like ZonedDateTime DateTime etc

Would be nice if we could do System.now().withHour(0).withMinute(0).withSecond(0).withNano(0) etc

Mostly for flexibility in the API, but there is cases where we don't want/need nanosecond precision, API calls, DB storage etc.

[dkhalanskyjb]

Duplicate of #325, please share your use cases in detail there. In particular, it seems at the moment that the needs for adjusting the precision for API calls and DB storage is already covered by rounding not at the moment of constructing the Instant but at the moment of serializing it to a string: https://kotlinlang.org/api/kotlinx-datetime/kotlinx-datetime/kotlinx.datetime.format/-date-time-format-builder/-with-time/second-fraction.html If not, please share what exactly you are trying to do that's inconvenient with our library currently.

[chrisjenx]

We use Exposed. Guess I could create a new db column but there's loads of places we use it. After parsing API requests from. Third party clients. It's pretty common.

[chrisjenx]

Also turning it to a string to remove milliseconds then back to an instant, is pretty poor performance wise.

[dkhalanskyjb]

We use Exposed.

I haven't used Exposed, so this doesn't tell me much, sorry.

After parsing API requests from. Third party clients. It's pretty common.

If I understood you correctly, third-party clients send you something like 2024-09-23T17:32:20.123456789, and you want to lower the precision and keep something like 2024-09-23T17:32:20.123, right? But why? What's the problem with keeping the whole 2024-09-23T17:32:20.123456789?

If you can give some examples of the code that is inconvenient to write and explain its purpose, it will help a lot. Pseudocode is also fine.

Also turning it to a string to remove milliseconds then back to an instant, is pretty poor performance wise.

That's not what I was suggesting. I meant that if you need to send a string somewhere anyway, you may as well lower the precision in the string itself, without rounding the Instant. If you want to receive an Instant, this approach won't work, yes.