My favorites | Sign in
Project Home Issues
New issue   Search
  Advanced search   Search tips   Subscriptions
Issue 5485: Clock on Droid set to GPS time, not UTC
80 people starred this issue and may be notified of changes. Back to list
Status:  WrongForum
Owner:  ----
Closed:  Jun 2013

Sign in to add a comment
Reported by, Dec 16, 2009
The clock on the Motorola Droid is ~15 seconds fast. This means its clock
is being set to GPS time instead of UTC. The GPS epoch began in January
1980 and there have been 15 leap-seconds since then. GPS does not recognize
leap-seconds so it leads UTC time by exactly 15 seconds.

Since just about everyone else in the world synchronizes to UTC time, this
means the Droid's clock is wrong.

I wrote an app, "SNTP Client", to perform an NTP query to measure the clock
offset. I have had other Droid users report the same 15 second offset.

15 seconds may not seem like a lot, but I have received reports that there
are apps that depend on a fairly precise clock that won't work correctly on
the droid because of this offset.

Hardware: Motorola Droid
Android: 2.0 & 2.0.1
Carrier: Verizon Wireless
Settings: Settings -> Date & time -> Automatic is checked.
Dec 18, 2009
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 
Jan 18, 2010
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).
Mar 20, 2010

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
"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."

Aug 7, 2010
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

Aug 18, 2010
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.



1.7 MB   Download
Aug 19, 2010
Wanted to query; is this also an issue with the Droid 2 / Droid X?  I don't have one to test.


Aug 19, 2010
@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? 

Aug 19, 2010
@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.


Sep 24, 2010
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.
Oct 11, 2010
My droid is allways out of sync, usually ahead, setting it to network time, does not help. 
Oct 11, 2010
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.


Nov 8, 2010
Confirming that the issue exists on HTC EVO 4G , running either ├ęclair or froyo, no matter what firmware update. 
Dec 3, 2010
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.  

Dec 30, 2010
This time on Droid X is also off. I used to use my cell phone time for accurately setting clocks, not anymore :(.
Mar 8, 2011
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.
Mar 8, 2011
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...)

Mar 8, 2011
Comment #15 on  issue 5485  by Clock on Droid set to GPS time, not UTC 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: 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.
Apr 6, 2011
The new HTC Evo Shift (4G running 2.2) also has this issue.
Jun 7, 2011
Gingerbread (Android 2.3.3) released June 3rd 2011 exhibits same issue on EVO 4G. 
Jun 19, 2011
Seems rather odd that his has been ignored so long.  Precision isn't optional.
Nov 22, 2011
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.

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

I've got an HTC Incredible, just updated to Gingerbread build 4.08.605.2 and the issue remains.
Mar 29, 2012
This remains an issue. It was brought up the other day on theverge.
Mar 29, 2012
I'd be interested to see/read that.  URL?

Mar 29, 2012
It's a video, you can watch it at the correct time with the link.
Mar 29, 2012
Dr. Neil deGrasse Tyson validates my theory?  I feel so special right now.

Mar 30, 2012
ZDNet picked up the story and linked to this issue, conveniently enough as well:
Mar 30, 2012
Wouldn't it be hard to fix this, for example hard-coding the "leap-second" fix or using another source for time?
Mar 30, 2012
My Samsung Galaxy S2 with 4.0.3 does not have this problem. Time is only about a second off from exakt.
Mar 31, 2012
I have a HTC Desire running CyanogenMod 7.2-RC1 and its time matches the time on
Apr 12, 2012
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.
Apr 12, 2012
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.)
May 7, 2012
I stumbled into this site and can't find a way to join-- I posted the comments below which posted as from My email is 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 seconds or seconds). 
Jun 28, 2012
Still a problem on the Droid 4.  Seriously?  All you have to do is parse the file:

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.

Jul 28, 2012
I'll confirm it's a problem with the Droid 4.
Nov 5, 2012
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.
Feb 3, 2013
#40 swivelgames
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...
Feb 3, 2013
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.
Feb 3, 2013
Is this only present on CDMA phones (I'm on Verizon) because they get their time from the GPS receiver at the nearest CDMA base station, and not the phone's internal GPS receiver?

Also, there is nothing wrong with syncing to GPS time vs UTC time.  They are two separate time scales which will both work when read and corrected properly.  The problem here is interpreting GPS time without applying the leap correction, which is part of the specification.

Feb 3, 2013
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.
Feb 28, 2013
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!
Mar 6, 2013
Happy to report that my Nexus 7 with Jelly Bean 4.2.2 now has accurate time.  Woot!
Mar 16, 2013
Sorry to report that my Verizon RAZR MAXX updated with Jelly Bean 4.1.2 this morning still does NOT have accurate time.

Apr 11, 2013
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)

Apr 11, 2013
Proposed issue title change:
Clock on CDMA devices not corrected for leap seconds when converting from GPS to UTC timescale

Apr 11, 2013
Still a problem with:
Motorola Droid 4
Jelly Bean 4.1.2 (update)
Jun 15, 2013
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.

Status: WrongForum
Sep 3, 2013
This report applies to multiple Android-based devices.

Status: CluelessMod
Sign in to add a comment

Powered by Google Project Hosting