Google just introduced a new API to provide a trusted time source <https://android-developers.google...

# kotlinx-datetime

[dawidhyzy]

Google just introduced a new API to provide a trusted time source https://android-developers.googleblog.com/2025/02/trustedtime-api-introducing-reliable-approach-to-time-keeping-for-apps.html?m=1.
Is there a way to use it with kotlinx-datetime?

[Stylianos Gakis]

Doesn't it just give you a more reliable way to get what System.currentTimeMillis() would return?

You could take that and do Instant.fromEpochMilliseconds(thisNewApi()) probably

[Tgo1014]

I wish this existed a few years ago hahaha

[dawidhyzy]

@Stylianos Gakis yes, I can, but it is error-prone, as you need to do it everywhere.

[dawidhyzy]

I was thinking about a way to provide to kotlinx-datetime a lambda that will be used whenever currentTimeMillis is taken

[hfhbd]

The client provides an Java Instant, so you can easily create a wrapper asClock that calls the conputeCurrentInstant (or use the unixTimeStamp and convert the instant to kotlinx Instant

[dawidhyzy]

Same problem as with the above

[dawidhyzy]

It can be workaround with some linting

[Stylianos Gakis]

So I am not sure what your question is here. What would you like to happen instead? No matter what is provided you can of course always use the wrong API and still have an issue.

[dawidhyzy]

I would like to have an option to override what is the source of current time when Instant.now() or Clock.System.now() is called

[hfhbd]

Why? Clock.System is a Clock. You should never hardcode Clock.System, but require a parameter with a Clock that can be mocked or used with a custom time source.

[dawidhyzy]

That’s a valid argument @hfhbd!

[dawidhyzy]

I can create a TrueTime object that implements Clock and force it’s usage by lint rule project wise

[hfhbd]

This is the way.
And a Clock parameter also works nicely with the coroutines-test testTimeSoure.asClock(origin = ) using the delay skipping behavior.

[Dmitry Khalanskiy [JB]]

Thanks for the link! This looks interesting, thanks. I don't think it's a good idea to replace Clock.System with this even when this API is available: if a user changed the device's time, they probably had a reason to do it, and we should normally respect that choice.

There's another reason why this has to be a separate `Clock`: if we don't want to respect that choice (for example, when we believe that the user may behave maliciously), then what should happen if the API is not available? Do we just fall back to the normal system clock? Do we want to block a user when we can't use the API? Do we want to print a message? Do we query our server for the timestamp? And so on.

In any case, soon, this question will be irrelevant to kotlinx-datetime, given that Clock and Instant go to the stdlib. My opinion is that the Clock implementation for TrustedTime should enter the KTX Android library: https://developer.android.com/kotlin/ktx I think it would be weird to add Android-specific implementations to the standard library.

[kevin.cianfarini]

Just to make this really clear the clock implementation would look something like:

class TrustedClock(private val client: TrustedTimeClient) : Clock {
  override fun now() = Instant.fromEpochMilliseconds(
    client.computeCurrentUnixEpochMillis()
  )
}

[dawidhyzy]

@Dmitry Khalanskiy [JB] I agree, Clock.TrueTime clock should be an addition and not a replacement of Clock.System. My initial assumption was incorrect.

[Dmitry Khalanskiy [JB]]

Doesn't computeCurrentUnixEpochMillis need to be a function call?

[kevin.cianfarini]

Yeah, sorry. Editing on mobile