3.5% of Android phone clocks are wrong by more than an hour(opensignal.com)
opensignal.com
3.5% of Android phone clocks are wrong by more than an hour
http://opensignal.com/reports/timestamps/
22 comments
In our experience, same applies to also iPhones, but the offsets tend to be time zone granularity. And a lot of users, especially from Asia, seem to use a U.S. VPN or a proxy of some sort. Their devices still have +8 hours or so time zone and an asian carrier name.
It's Candy Crush's fault.
Title is total link bait. Article says 3.5% of Android phones clocks are off by 15s and that in some cases there are time zone edge cases causing it to be off by an hour. This is not what the title conveys.
Actually 3.5% of android clocks ARE out by one hour or more... the 15s bug effects some phones, but the problem of being more than an hour out is very general and does effect 3.5% of phones - sorry if that's not clear!
They explain the math pretty clearly under the heading "How Widespread is This?"
[deleted]
>The time displayed to the user will seem correct
This gets into fuzzy definitions of "correct" here. If the phone is showing the right local time, but internally has the wrong UTC time, does it matter?
This gets into fuzzy definitions of "correct" here. If the phone is showing the right local time, but internally has the wrong UTC time, does it matter?
Yes. With many two-factor authenticator applications, your codes won't work if your clock is wrong.
Two-factor authenticator applications should be using UTC, and not the display time. I think that's what the parent comment's point was.
Right, but these phones have the wrong UTC, if I understand correctly. That's why they are in the write-up. Wrong local/display time is pretty hard to detect, unless you have coordinate data.
Given that, two factor where the second factor is a local authenticator program is not exactly a common thing.
Given that, two factor where the second factor is a local authenticator program is not exactly a common thing.
And the UTC would be wrong.
My Android phone (a Motorola Atrix) has issues when I cross timezones. For the past few months, I've been travelling between Chicago and Raleigh on a near weekly basis, and I find pretty consistently that when I land in either city, my phone doesn't update the time from the network, to reflect the local time zone. So, if it were showing the time on the East Coast when I left Raleigh, I could land in Chicago and 2 days later my phone will still have East Coast time, unless I physically reboot it. And vice versa going the other way.
I don't know if it's a reflection of the same problem(s) talked about in this article or not, but I know it's incredibly annoying.
I don't know if it's a reflection of the same problem(s) talked about in this article or not, but I know it's incredibly annoying.
In the UK most 3G networks do not give out the time. In Belgium they seem to.
Why NTP is not running as standard I have no idea. You have to root your phone to run it.
Why NTP is not running as standard I have no idea. You have to root your phone to run it.
GPS is also a source of time.
Although not a great source of time zone info unless you have a big database to back it all up.
My old phone (LG Thrill) had a bug where the clock would simply stop syncing for some unknown reason. It could be hours out of date at any given time. The only way to resolve this was to restart the phone. Of course, it was never fixed before LG abandoned the phone. There were other very serious problems with that phone, and the whole experience put me off Android.
This was an issue for our app. We went SSL-only for our API, which unfortunately fails with a cryptic error message if the clock is off. We eventually messages this to the user ("Sorry, Zite is broken, please reset your clock"), but there's no way to know how many users actually went and fixed it and returned to the app.
The Google Play Store app on Android is also affected by this. It'll just show a generic "unable to connect" message if your clock is too far off, which I assume is related to the same SSL problem.