IssueTracker

I've noticed the issue on my Droid as well; I wear a Citizen "radio controlled" watch.  Also setup
& admin of Symmetricom SNTP time servers @ work, so I'm used to paying attention to time
inaccuracies.

This is a potential security hole as well, as some high-security applications depend
upon a synchronized clock between client and server, in order to prevent "replay"
attacks (eg, like replaying a bank funds transfer transaction).

Hi,

This may be happening on specific GPS hardware only.

The difference between my Samsung Galaxy i7500 Android phone and NTP Client is just 3
seconds. The time reported from another GPS receiver is within 1 second from the time
reported by NTP Client

According to http://en.wikipedia.org/wiki/GPS_time#Timekeeping:
"The GPS navigation message includes the difference between GPS time and UTC, which
as of 2009 is 15 seconds due to the leap second added to UTC December 31, 2008.
Receivers subtract this offset from GPS time to calculate UTC and specific timezone
values. New GPS units may not show the correct UTC time until after receiving the UTC
offset message."

My Moto Droid A855 is off by 14 seconds right now, and before I read this, I wondered why it was always off.

Can anybody recommend the best way to have the system clock set itself to the exact "current time" as opposed to the GPS time (which apparently is off by 15 seconds and growing). From the wiki article above I learned that the GPS signal also transmits the GPS to UTC offset, so with that information the clock should have everything it needs to sync to UTC.

I suspect that even if I set the time on my device manually, it will just get re-set at the next scheduled sync up or cell-location-changed....

08-07 16:23:11.249 D/AlarmManagerService( 1038): Kernel timezone updated to 240 minutes west of GMT
08-07 16:23:11.257 D/SystemClock( 1165): Setting time of day to sec=1281212591

The GPS signal contains an 8-bit correction string which allows for up to 255 seconds of correction.  The A855's GPS chipset (SiRFStar III) receives both the GPS Time and the correction, then applies this correction to output UTC Time as NMEA sentences via either $GPRMC or $GPZDA.  

However the SiRFStar III also supports a binary interface mode which outputs time data in a more "raw" form.  The time string from binary mode is GPS Time (not UTC) and applying the correction string is handled either by a firmware routine or at the OS level.

I'd be willing to bet a lot of money that the A855's SiRFStar III is interfaced via the binary mode for at least two reasons; faster data I/O rate (NMEA is limited to 4800 bps) and the ability to enter Low Power Mode.  

The UTC correction is derived from the payload data of binary Message ID 52 ("1 PPS Time").  Message ID 52 outputs either UTC Time (if the chip has valid and up-to-date correction data) or GPS Time (if the data is corrupt or older than 2 weeks).  Message ID 52 outputs the UTC Offset as 2 signed bytes (Offset Integer) and 4 unsigned bytes (Offset Fraction) in nanoseconds.  Refer to the attached interface spec PDF.  

I suspect that clock time is being computed from other sources, such as Message ID 7 ("Clock Status Data").  

Hope this was helpful.

Best,

...dtw

Wanted to query; is this also an issue with the Droid 2 / Droid X?  I don't have one to test.

...dtw

@dtwitkowski Great info. I'm still wondering if there is a way to force a phone, such as the a855, to use the correct time for its system clock rather than the uncorrected time?

@linuxbrad: I suppose that a rather inelegant method to resolve this issue would be for the Android OS team to add an option into the Date & Time settings allowing for manual entry of a GPS Time correction of integer seconds.  This correction would have to be applied even if the "Automatic" option is set on.  

Because the difference between GPS Time and UTC Time only changes (at a gross level) every time NIST decides that UTC needs to be corrected via "leap seconds", a manual adjustment to the Droid's clock by subtracting a manually entered correction (in seconds) would be crude but largely effective.  There is also a nanosecond-level correction factor which is available as part of the GPS data stream, but the Droid is hardly a stratum-1 time device and an error of even 100 milliseconds isn't going to be noticeable or relevant.  

The drawback of a manually-entered correction integer is that every few years the user will need to manually update the correction integer if NIST makes a leap second correction to UTC.  Incidence of leap second corrections are fairly well-publicized and the current difference between GPS Time and UTC Time is easily obtainable online.

Obviously the "right" way to deal with this would be for Motorola to patch their GPS device driver.  If not, then hopefully the Android OS team will see the wisdom of patching the problem by adding an option to input a correction integer.

...dtw

I can confirm this is happening on the Droid X and I find it very annoying.  I always like to know the precise time and wish my Droid X would report it correctly.

My droid is allways out of sync, usually ahead, setting it to network time, does not help.

FYI recently upgraded from Droid 1 (Motorola A855) to Droid 2 (Motorola A955) and have confirmed that the problem exists on the Droid 2.  I'd be interested to know if the same problem exists on other Motorola Android platforms.

...dtw

Confirming that the issue exists on HTC EVO 4G , running either éclair or froyo, no matter what firmware update.

It seems to ne that the phones' GPS chipsets are not at stake, as some users never turn on GPS, so as to save power or privacy reasons, and also I noticed that basic Sprint phones with no GPS circuit still show UTC-referenced time. Also the Samsung EPIC that currently runs Android 2.1 does not exhibit the issue.
Not sure whether the providers are only broadcasting GPS-reference, and then firmware is expected to apply the offset, or whether Android is expected to bias network time.
Note that on the EVO 4G seconds cannot be adjusted in manual mode, i.e. the set time function only sets hours and minutes and still uses network-provided value for seconds (!). Root authority is needed for all NTP software assuming someone needs a stopgap measure.  

This time on Droid X is also off. I used to use my cell phone time for accurately setting clocks, not anymore :(.

I recently participated in a TSD (Time Speed Distance) Road Rally and was astounded by the fact that I couldn't synchronize my time with the rally organizer's official start time.  Interestingly I was off his time by about five seconds... I downloaded an app called ClockSync in the hopes this would give an option to manually adjust.  Nope, synchs up the time with the atomic clock.  My five second discrepancy changed to a 19ish second discrepancy.  DOH. Ultimately I found a version of a rally app that allows you to reset the clock manually.  Unfortunately, the paid version is >$100.00 USD and the lite version crashes.

It's really amazing to me that this problem has gone unaddressed, and indeed continues to appear in newer models.  Some app developers (from example in the amateur radio world; the NCDXF Beacon Tracker) have addressed the time difference in the app itself.  While not ideal, this will work.  Drawback is that every time NIST declares a UTC correction they'll have to update their app, but this likely only happens every 2 years or so.  This leads to a point; if Google/Motorola can't fix the driver, then why not add a UTC Correction setting into the Time/Date control panel?  I guess this might involve admitting that they made a mistake.  Hopefully ROM developers like CyanogenMod will address this in their offerings.  Now if only they would release CyanogenMod for Droid 2...  (Folds hands in prayer and looks skyward---Oh please oh please...)

Comment #15 on issue 36911516 by tabru...@gmail.com: Clock on Droid set to GPS time, not UTC http://code.google.com/p/android/issues/detail?id=5485 I recently participated in a TSD (Time Speed Distance) Road Rally and was astounded by the fact that I couldn't synchronize my time with the rally organizer's official start time. Interestingly I was off his time by about five seconds... I downloaded an app called ClockSync in the hopes this would give an option to manually adjust. Nope, synchs up the time with the atomic clock. My five second discrepancy changed to a 19ish second discrepancy. DOH. Ultimately I found a version of a rally app that allows you to reset the clock manually. Unfortunately, the paid version is >$100.00 USD and the lite version crashes. -- You received this message because you starred the issue. You may adjust your notification preferences at: https://code.google.com/hosting/settings Reply to this email to add a comment.


I haven't been on a TSD rally for years! There's an app called "navy clock", I think, that displays both GPS and universal time.

The new HTC Evo Shift (4G running 2.2) also has this issue.

Gingerbread (Android 2.3.3) released June 3rd 2011 exhibits same issue on EVO 4G.

Seems rather odd that his has been ignored so long.  Precision isn't optional.

Another app which has been reporting this difference to me, and I never understood why Verizon's time base would be so far off till now, is Micro Second.

http://www.appbrain.com/app/micro-second/com.landak.microsecond

The NIST U.S. Time widget is another nice quick place to check your clocks.

http://www.time.gov/widget.html

I've got an HTC Incredible, just updated to Gingerbread build 4.08.605.2 and the issue remains.

This remains an issue. It was brought up the other day on theverge.

I'd be interested to see/read that.  URL?

It's a video, you can watch it at the correct time with the link.

http://youtu.be/ekc3uRPlILU?t=56m15s

Dr. Neil deGrasse Tyson validates my theory?  I feel so special right now.

ZDNet picked up the story and linked to this issue, conveniently enough as well:

http://www.zdnet.com/blog/hardware/the-time-displayed-on-most-android-phones-is-wrong/19387

[Comment deleted]

Wouldn't it be hard to fix this, for example hard-coding the "leap-second" fix or using another source for time?

My Samsung Galaxy S2 with 4.0.3 does not have this problem. Time is only about a second off from exakt.

I have a HTC Desire running CyanogenMod 7.2-RC1 and its time matches the time on www.time.gov

This is a genuine problem for software like RSA's soft tokens that depend on close time synchronization between the client and server. RSA's model uses a pseudo-random number generator which generates a new sequence once per minute. So if the time is significantly of sync (for example, 15+ seconds), then the value displayed on their device may not be considered valid by the server.
I discovered this today when I installed the RSA soft token software on both my Android phone (a Motorola Droid X2) and an iPad 3, and loaded the same base token value into both of them. At first I thought something was wrong because they weren't displaying the same code. Then I realized that the Android device was just about 15 seconds "in the future" compared to the iPad.
Because the codes change once per minute, and the previous code is not displayed, a 15-second lag means that users only effectively have 45 seconds to enter the code, rather than 60 seconds, and they have to know not to enter it until the countdown timer in the soft token software displays 45 seconds left.
My organization may be unusual, but one of our standard troubleshooting steps for RSA users is to tell them to "wait until the code has just changed, then enter the new one", so that they are more likely to enter it before the 1-minute countdown expires. In the case of Android users, this is actually terrible advice with the current time synchronization method.

It's not well documented, but this isn't actually a problem with RSA tokens. As long as the time is reasonably in sync, the server will actually slew its idea of the client's time based on when the token is entered. (e.g. if the user is consistently entering tokens 15 seconds after they should have become invalid, the server will learn that the client's clock is 15 seconds slow and compensate.)

[Comment deleted]

[Comment deleted]

I stumbled into this site and can't find a way to join-- I posted the comments below which posted as from limespill.com@gmail.com. My email is jmd2081@gmail.com. I'm not an app developer but I produce audio and multi-cam video and I stay in touch with tech issues, and I follow up on issues like this one-- time. Can I join up? Please let me know.

Very glad I found these postings. I first noticed the 15 second problem when I tried an HTC Resound a couple of months ago-- it was about 34 seconds off. (I didn't keep it). I then checked my Droid X, and found it was always 14 to 15 seconds fast. Calls to Verizon ("If it's over a minute off we're concerned") and today to Motorola ("15 to 30 seconds isn't a problem"), getting to 2nd level tech-- no one knew the problem is the GPS time reference...   Curiously, my second Verizon phone line is hooked to my old reliable LG 6100, which isn't 3G (I think). It syncs perfectly with my atomic-synced wrist watch and wall clock and always had. I'm really pissed that Verizon and Motorola haven't told their techs (the ones I can talk to) about the GPS / UTC business. Thank you all for finally having a reasonable answer. Now if only there will be an app or fix from Motorola -- I'm getting a Droid Bionic tomorrow, but I imagine it will also be 15 seconds fast (well, actually, my manual calculations and Clocksync [one of the apps which shows Atomic time and your phone's time and any discrepancy and has a 5 second beep countdown to reset the time, but of course doesn't help since the Droid X will only set to minutes and hours while the seconds remain 15 ahead] show either 14.xxx seconds or 15.xxx seconds).

[Comment deleted]

Still a problem on the Droid 4.  Seriously?  All you have to do is parse the file:

http://maia.usno.navy.mil/ser7/tai-utc.dat

and know that

GPS = TAI - 19 s.

It's going to get worse again on July 1 2012 when another leap second is introduced.  This is like rookie-level fundamental failure of time systems.

I'll confirm it's a problem with the Droid 4.

My T-Mobile myTouch Q (Huawei running Android 2.3.6) is synced to "network time" and is 15 seconds behind UTC.  That is, when the clock on my desktop (synced to UTC) reads 13:16:15, the clock on my phone changes from 13:15 to 13:16.

Still a problem, Nexus S, Android 4.0.1

The status of this is `new`. This seems like an incredibly simple bug. Why has no one addressed this? I agree, this is rookie-level... just like the Email IMAP issue that took years to "get around to". Checking the time is one of the most common uses of the cell phone along with making calls and sending text messages. Those three are the most common uses for a cell phone. One of the most common uses of the cell phone is handicapped because someone doesn't know how to do time systems math.

Seriously, guys. Can we fix this please? Ridiculous...

It looks like this is no longer a problem on the latest version of Android. I'm running a stock Nexus 4 with Android 4.2.1 and my clock is accurately using UTC and not GPS time.

[Comment deleted]

Might as well say there would be nothing wrong if Android used the Julian calendar, because it only requires a correction. UTC (offset to local time zones) is the legal time in most jurisdictions.

Please fix... I ask Google Now the time and it knows it..  Why is my android phone have the incorrect time please and thanks fix meow!

Happy to report that my Nexus 7 with Jelly Bean 4.2.2 now has accurate time.  Woot!

Sorry to report that my Verizon RAZR MAXX updated with Jelly Bean 4.1.2 this morning still does NOT have accurate time.

The same for Samsung Galaxy S2 (SPH-D710, CDMA Sprint)
Time is incorrect for 15-16 seconds on stock ICS 4.0.3, on Cyanogen 10 (JB 4.1.2), on Cyanogen 10.1 (JB 4.2.2)

[Comment deleted]

Still a problem with:
Motorola Droid 4
Jelly Bean 4.1.2 (update)

This report applies to an Android-based device, and the issue tracker where you reported it specializes in issues within the Open Source source code of the Android platform.

We are not able to provide support for individual devices. Please report this issue in the support forum for your device, which might be hosted by your device manufacturer or by the operator where you got your device.

This report applies to multiple Android-based devices.

Status: CluelessMod

My HTC Droid Incredible has always been off by about 15 seconds, until today. As of today, the error is under one second (per the ClockSync app). I suspect maybe Verizon changed the network time reference in conjunction with the switch from Daylight to Standard time at 2:00 am yesterday.

Bill Starr
Columbus, Indiana
Mon, 3 Nov 2014, 8:55 am EDT

Well, that didn't last long. My phone is back to its usual 15.7 seconds fast again.

Mon, 3 Nov 2014, 1:54 pm EST

Now on a Motorola Moto G, which started off as 4.4.2 and is now 4.4.4.

Have not had this problem on my new phone.

Good point at #50: this problem is specific to certain devices, apparently from Motorola, HTC, and Huawei. If a device doesn't provide the right time to the Android OS, it's hard to see what the OS can do. If your camera doesn't work, you generally shouldn't try to fix it in the operating system either.
So has anyone reported this to Motorola, HTC, Huawei, etc?  Providing links to their issue trackers would help others avoid this problem and find the right forum.

Now on Lollipop 5.1 on the Moto G, and still no problem. I'd agree it is device specific, not OS specific. Had the problem on the A855 Droid and the Droid 4, but not on the G.

tablet reset to dec. 2009 5:08 pm is this a bug or what?

A few thoughts on this issue for historical reference... The idea that the 15-second offset was related to GPS Time and leap seconds was merely a hypothesis and one without any apparent basis in fact. Far more significant, from my perspective, was the fact that the earliest iPhones (first generation) displayed a very similar offset of approximately 15 seconds. There's no way to know, since the code is proprietary, why that offset existed. But it is quite possible that leaked examples of the code (which we KNOW were circulating) were copied by the early Android development team --a bit of "lateral gene transfer". Note that this, too, is just a hypothesis, but it seems to fit the evidence better.

Arguing against the GPS theory, based on my own observations (admittedly imperfect!), the 15-second offset on very old Android devices has remained constant despite the addition of more leap seconds in the time since this thread was running. It's hard to be sure since the normal "noise" in the synchronization of the system clocks is on the order of 1 or 2 seconds, but 'on average' the difference seems to be fixed at 15 seconds. Further evidence against the GPS theory: devices booted up completely shielded from GPS signals (indoors, away from windows, e.g.) also display(ed) the 15-second offset. They were not getting time from GPS signals.

Incidentally, since Tyson's comments on this topic were mentioned... I met with Neil deGrasse Tyson at a conference on the future of UTC and leap seconds (a small conference, 18 participants) near Philadelphia in late 2011. He mentioned then that he "had heard" that the Android time scale was wrong because it failed to take account of leap seconds. This was an Internet rumor in tech circles at that time. I explained to him then that this was "just a guess" by some programmers and that I saw no evidence for it, but he liked the leap second theory, and that's how it ended up in that interview back in Spring, 2012. The point of this is that Tyson's comments were not evidence or confirmation in any way. He was just repeating something that he had heard and he liked --because it provided a nice segue to related issues in science.

Frank Reed
ReedNavigation.com/aboutfer