Android clock errors: June, 2013

Errors in Android Clocks

At OpenSignal, each datapoint we collect has two timestamps: the time the reading was taken and the time the reading was inserted into our server. Because we make extensive use of SQLite cacheing on devices, these times can be far apart - sometimes up to the order of weeks. The app reading time, however, should always be before the server insert time, otherwise you have an apparent violation of causality. When we noticed this happening occasionally, we took a closer look and found widespread difficulties getting accurate time readings.

We uncovered various causes of these Android time discrepancies: a bug in Android's setting of time via GPS which produces a 15s error; disagreements of one hour caused by Time Zone edge cases and perhaps also by a system bug in the application of timezones; and deliberate manual adjustments to the system clock time in order to fool games.

Distribution of time differences

When the Android clock is synchronized correctly, this time difference is always negative

We'll focus on the time difference between the timestamps of speedtests taken in-app, and the timestamps for when they arrive at the server database.

Time difference = App time - Server time

If all phone clocks and our server clock were synchronised this would always be negative and usually quite small, since the app will attempt to upload a speedtest immediately after it has run. If the upload fails, it will wait until the next speedtest is run.

Looking at the last million speedtests run, this is the distribution found when restricting the dataset to just one minute either side of zero (density = frequency density).


Drawing out the salient features, we see some behaviour that is to be expected and some that is rather curious:

Contact Sales

Are you having trouble with the OpenSignal Apps and need some help?

Are you a mobile operator or analyst and want to contact a sales expert?

Share Graph