so `Clock.System.now().toEpochMilliseconds()` is the equivalent of `System.getCurrentMillis()` ?

# kotlinx-datetime

[Nikky]

so Clock.System.now().toEpochMilliseconds() is the equivalent of System.getCurrentMillis() ?

[ilya.gorbunov]

Yes

[louiscad]

kOtLiN iS sO vErBOse

[Marc Knaup]

I don’t like that approach because it’s a memory allocation rather than just providing a Long.
Clocks should provide epoch millis without intermediate Instant.

[louiscad]

Isn't Instant an inline class? If not, maybe it'll be once they are stabilized?

[Marc Knaup]

No, because just like Java’s Instant it uses one Long and one Int to provide the needed precision.

[louiscad]

I guess value types might help here, once they land in the JVM and in Kotlin (and on Android somehow though with drawbacks?)

[ilya.gorbunov]

@Marc Knaup Why do you need those millis in the first place?

[Marc Knaup]

I’ve seen three situations so far:
• For time measurement (but we have kotlin.time for that now 👍)
• For use with Java libraries (will go away over time)
• For code that allocates a huge amount of objects where the performance and/or memory impact of Instant becomes noticeable (fortunately that’s rare for me)

[Marc Knaup]

Today we can have projects where we use many different Date classes at the same time.
We’ve got Date, Instant (Java), Timestamp (own time lib), GMTDate (ktor) and Instant (kotlinx-datetime).
Converting between all those is based on epoch millis and often intermediate instances of either of them are created. That’s annoying when I want to optimize for high performance low memory when that’s done tens of thousands of times.
Usually the current time in millis is used to compare one of those dates with the current system time, e.g. to check if a specific date has passed.

[Marc Knaup]

An alternative for this use case would be a specific API for it.
clock.durationSince(timestamp) and clock.durationUntil(timestamp). Then I can check without allocation if a certain date (with leeway) has passed.

[louiscad]

@Marc Knaup You don't always need Instant, kotlin.time can suit several use cases. Take this snippet for example: TimeSource.Monotonic.markNow().hasPassedNow()

[Marc Knaup]

I don’t have a mark for the date I compare to if it comes from other API.
E.g. the expiration date of an HTTP request.

[Marc Knaup]

Or some date from a database

[louiscad]

You can convert a date to a TimeMark I think

[louiscad]

And you can implement your own TimeSource

[Marc Knaup]

I have no idea, but it doesn’t sound cheap either

[Marc Knaup]

And definitely not easy 😅

[Marc Knaup]

@Marc Knaup You don’t always need Instant, kotlin.time can suit several use cases. Take this snippet for example: TimeSource.Monotonic.markNow().hasPassedNow()

Also, that doesn’t account for leeway. What if I want to check “I’m 5 seconds after `Instant`“?

[louiscad]

You need to convert Instant to a TimeMark beforehand.

[louiscad]

Which is a little bit of math in a write once extension function I think

[Marc Knaup]

That would mean changing my entire data model for no good reason 🤔

[Marc Knaup]

If I convert it on the fly I’m back to the initial problem of performance and/or memory hit in code that’s used in high volume

[louiscad]

You can't cache/memoize the conversion from Instant to TimeMark?

[Marc Knaup]

Not without changing the model of the data where the Instant are coming from.
And even then - it’s just way too complicated for something as simple as comparing time against the clock efficiently.