Use network time instead of device time

[marandaneto]

Description

Relates to https://github.com/PostHog/posthog-android/issues/223

Description

• [x] Android
• [ ] iOS
• [ ] Flutter
• [ ] RN

Alternatives: https://android-developers.googleblog.com/2025/02/trustedtime-api-introducing-reliable-approach-to-time-keeping-for-apps.html?m=1 https://developer.android.com/reference/android/os/SystemClock#currentNetworkTimeClock() (API 33) https://github.com/instacart/truetime-android

Analytics data, recordings, etc, all depend on the timestamp. The server does clock drifting if it's off in the past or future, but that's not ideal. Devices can be way in the past, future or just off by a few minutes due to user's settings, I believe using a network time would be way better

[marandaneto]

@ioannisj does iOS provide something that syncs the clock or is it synced already?

eg https://github.com/instacart/TrueTime.swift and https://github.com/comyar/Chronos-Swift

[ioannisj]

@marandaneto no, iOS will suffer from the same limitation here. So turning off automatic date sync and using a custom date in phone settings will affect what's returned by NSDate(). So the solution should be an NTP which also has the limitations of handling network errors, init latency etc. I've used TrueTime before but not in scale. Chronos-Swift seems a bit unrelated?

Would this fall in the SDK responsibility though or should the sdk just expose a config where people can overwrite date based on their specific NTP implementation?

[ioannisj]

Otherwise we may want to rely on PostHog net time using /decide or similar endpoint for example? Initial thought was remote config but that's cached

[marandaneto]

Chronos-Swift seems a bit unrelated?

@ioannisj linked the wrong (super old) one https://github.com/MobileNativeFoundation/Kronos

So the solution should be an NTP which also has the limitations of handling network errors, init latency etc

syncing should be async and offset cached, so you dont have to delay app start.

Would this fall in the SDK responsibility though or should the sdk just expose a config where people can overwrite date based on their specific NTP implementation?

it all depends on the solutions we find. Android has provided a class that syncs automatically from the latest version, so we use that one if available. using 3rd party deps is always not a good idea, but can be an optional dependency if enabled, etc.