Clock Sync in applications — essence, protocols and implementation

What is Clock Synchronization?

Clock synchronization (Clock Sync) is a mechanism for aligning a device’s internal clock with the reference UTC time (Universal Coordinated Time). Without synchronization, the quartz crystal oscillator in a mobile device gradually drifts — the drift is 1–10 seconds per day depending on temperature and component quality. Synchronization compensates for this drift by obtaining accurate time from external sources: NTP servers on the internet, GPS satellites, or cell towers. Ideally, a device should synchronize every 4–6 hours to maintain accuracy within 1 second.

Hardware and Software Clocks

A mobile device has two types of clocks: hardware (RTC, Real-Time Clock) with a separate battery backup — they continue running even when the device is off, and software (system time), managed by the operating system. Upon boot, the system time is initialized from RTC and then maintained via clock generator interrupts. NTP synchronization corrects system time, and in some cases, writes the correction to RTC as well. On Android, access to the hardware RTC is restricted — apps cannot modify it without root access.

Why Time Synchronization is Needed in Mobile Apps

Many aspects of mobile app operation critically depend on accurate system time. SSL certificates have validity periods: if the device’s time is set before the certificate issue date or after its expiration date, the HTTPS connection will be blocked. OAuth tokens and JWT authentication use timestamps to check expiration — desynchronization leads to false authorization failures. Push notifications are scheduled by time, and if the clock drifts, the user receives notifications at the wrong time or doesn’t receive them at all.

Consequences of Desynchronization

Application security also suffers from incorrect time: time-based encryption (time-based OTP), event logs with incorrect timestamps, incorrect rate-limiting on the server side (the server blocks “future” requests). According to the OWASP Mobile Top 10 (2024), distrust of system time falls into the category of insufficient platform security. Developers are advised to always check time on the server rather than rely solely on client clocks. If the discrepancy exceeds a threshold (5 seconds is recommended), the application should block critical operations until synchronization.

Synchronization Protocols: NTP and SNTP

The main protocols for clock synchronization are NTP and its simplified version SNTP. NTP (RFC 5905) is a full protocol with server filtering, drift analysis, and PLL correction. It is used on servers and network equipment. SNTP (RFC 4330) is a lightweight version for client devices that do not require constant synchronization. An SNTP client sends a request, receives a response, and sets the time without history analysis. On mobile devices, SNTP is specifically used — Android’s built-in Google Time Service (GTS) synchronizes via SNTP with time.google.com servers.

Additional Synchronization Methods

Besides NTP/SNTP, time synchronization on mobile devices is possible via GPS receiver (accuracy up to 10 ns in ideal conditions) and cellular network (via NITZ — Network Identity and Time Zone). GPS provides maximum accuracy but works only outdoors and consumes a lot of power. NITZ is provided by the cellular operator automatically upon network registration, but not all operators support it. Android uses a combination of all methods: GTS (SNTP) as priority, NITZ as backup, and GPS for applications requiring high accuracy.

Synchronization Problems in Distributed Systems

In distributed systems — when the server and client are on different devices — clock synchronization faces fundamental limitations. Network latency makes it impossible to unambiguously determine the exact time on the client: if a packet took 200 ms, the time on the server at the moment of request and response is already different. NTP solves this problem through RTT measurement and statistical processing, but for distributed transactions (e.g., bank transfers), this is insufficient — logical clocks (Lamport timestamps) or vector clocks are used.

Physical vs. Logical Clocks

Physical clocks (wall clock) — real UTC time, synchronized via NTP. Logical clocks — ordinal numbers of events in the system, not tied to physical time. In distributed systems, vector clocks are often used for event ordering: each node stores a counter vector for all cluster nodes. For mobile applications, physical synchronization with 1–5 second accuracy is sufficient — this ensures correct operation of OAuth, SSL, and push notifications. If strict event ordering is required (e.g., in real-time chats), logical synchronization is added at the server level.

Implementing Clock Sync in Android

Implementing clock synchronization in an Android application can be done in several ways. The simplest is to get server time via REST API: the server returns a Unix Timestamp in the response body or in the HTTP Date header. This approach requires no additional libraries and guarantees the time matches the server. The second way is to use an SNTP client for direct queries to an NTP server. The third is to rely on Android Google Time Service, which automatically synchronizes system time if the device is connected to the internet.

Comparison of Approaches for Android

In Android applications with authorization and financial operations, a combined approach is recommended: with each API request, the difference between server time and System.currentTimeMillis() is saved. This difference is applied to all time calculations on the client, regardless of whether the system clock is synchronized. This approach is called clock skew correction and is implemented through a class that stores the last known server difference. Additionally, background NTP synchronization can be run every 4–6 hours via WorkManager.

// Clock skew correction
class ClockSyncManager {
    private var serverTimeDiff: Long = 0 // serverTime - deviceTime (ms)

    fun updateServerTime(serverTimestampMs: Long) {
        serverTimeDiff = serverTimestampMs - System.currentTimeMillis()
    }

    fun getCorrectedTime(): Long {
        return System.currentTimeMillis() + serverTimeDiff
    }

    fun isSyncValid(maxDiffMs: Long = 5000): Boolean {
        return Math.abs(serverTimeDiff) < maxDiffMs
    }
}

Background Synchronization via WorkManager

For periodic background time synchronization on Android, use WorkManager with PeriodicWorkRequest. The synchronization task performs an SNTP request or REST API call, obtains server time, and updates ClockSyncManager. The minimum interval for PeriodicWorkRequest is 15 minutes, but for time synchronization, 4–6 hours is sufficient. When synchronizing, consider the network state — use NetworkType.CONNECTED to prevent unnecessary requests while roaming. If synchronization fails, save the previous correction — it remains valid with gradually decreasing accuracy.

Automatic Time Synchronization on Devices

Modern mobile devices synchronize time automatically through built-in services. On Android — Google Time Service (GTS), part of Google Play Services. On iOS — an NTP client built into the operating system. These services work independently of applications and require no additional configuration. The user can disable automatic synchronization in settings, creating a risk for apps — this is precisely when the developer needs to implement their own synchronization. It is recommended to check the auto-sync status via Settings.Global.getInt(AUTO_TIME) and warn the user when it is disabled.

Recommendations for Developers

Relying solely on automatic synchronization is dangerous — the user may disable it or be in an area without internet. Best practice is to obtain time from the server with each API request and store the desynchronization in SharedPreferences or DataStore. For critical operations (payments, authorization, document signing), always check isSyncValid() before execution. If desynchronization exceeds the threshold — show the user a screen suggesting to enable auto-sync or wait for synchronization. For gaming and entertainment apps, it is sufficient to get time from the server on startup and update once an hour.