The iPhone time goes backwards: a time warp maybe?

I’m developing an iPhone application which logs GPS data in a SQLite DB, including their timestamps.

When I’m running the application while I’m stationary, the timestamps are exactly what you’d expect, i.e., they matches the actual time shown by a wall clock, and sequential samples have increasing times.

However, when I run the application in a moving car, I notice that every 5-10 minutes or so the timestamp jumps back in time, sometimes by as much as 30 seconds.

For example, I might have a GPS reading with a timestamp of, say, today at 10:10:30, and the next GPS reading would have a timestamp of 10:10:01. After this happens, subsequent samples are well behaved (time is increasing), until after another 5-10 minutes when the time resets back again.

To check whether this problem is only related to the GPS, I started writing in the SQLite DB also the actual time [NSDate date] in which the location manager reports a new point. This time almost equals the GPS sample’s timestamp (within a few mS), and is also subject to the same occasional reset back of 10-30 seconds.

Has anyone seen this? Could it be a result of synching the iPhone time to that of cells along the way? If so, aren’t cells supposed to be synchronized to an atomic clock? If indeed it’s the time difference between cells, why wouldn’t the iPhone sync with the GPS time, which is atomic?

Does anyone know how to solve this, i.e., having monotonically increasing timestamps?

iPhone 3G, iPhone OS 3.0.1

Posted on Aug 11, 2009 9:51 AM

Reply
Question marked as Top-ranking reply

Posted on Aug 12, 2009 9:22 PM

Thanks a lot Learning Annex Certified, that solved my problem.

Indeed mach absolutetime() is available on the iPhone, and seems to be the only reliable way to tell the time difference between two subsequent GPS readings. One should not reply on the samples’ timestamps, because from time to time subsequent timestamps go back in time as described in my first post above.

Caveat: the timestamp provided by the Location Manager is supposed to be the exact time in which the sample was taken. When one uses mach absolutetime() when a new point is available, there’s a small delay between the sample and the call of locationManager:didUpdateToLocation:fromLocation:, but hopefully the variance in the delay is small so the delta time between two samples is accurate.

Now, if only mach absolutetime() would have been available on Win98.
8 replies
Question marked as Top-ranking reply

Aug 12, 2009 9:22 PM in response to Learning Annex Certified

Thanks a lot Learning Annex Certified, that solved my problem.

Indeed mach absolutetime() is available on the iPhone, and seems to be the only reliable way to tell the time difference between two subsequent GPS readings. One should not reply on the samples’ timestamps, because from time to time subsequent timestamps go back in time as described in my first post above.

Caveat: the timestamp provided by the Location Manager is supposed to be the exact time in which the sample was taken. When one uses mach absolutetime() when a new point is available, there’s a small delay between the sample and the call of locationManager:didUpdateToLocation:fromLocation:, but hopefully the variance in the delay is small so the delta time between two samples is accurate.

Now, if only mach absolutetime() would have been available on Win98.

Aug 11, 2009 10:23 AM in response to K T

Thanks for the warm welcome (indeed, it's kind of awkward to click the first "post message" ever...).

I am using iPhone 3G with the latest 3.1 beta. I've had this problem since I started developing the app, several months ago and several OS versions ago.

The interval is as fast as the Location Manager feeds me data, which is about every 0.5 seconds on average when the device is moving (in a car). I record about 6000 samples per hour.

Tsachi

Aug 12, 2009 10:02 PM in response to Tsachi

Hi--

Tsachi wrote:
One should not reply on the samples’ timestamps, because from time to time subsequent timestamps go back in time as described in my first post above.


Yeah, that's expected behavior. What happens is that the Location Manager gets its location several different ways. Some ways take longer than others, and so the sample with the older time stamp might be from a different method.

charlie

Aug 13, 2009 7:06 AM in response to Charles Minow

Charlie,

Thanks for your reply. Indeed, the time delta between timestamps of two subsequent GPS readings can be negative also because of what you describe. However, I was talking about another phenomenon, which (I now realize) can be seen even without the Location Manager -- the issue of
NSDate *t = [[NSDate date]];
occasionally going back in time when the device is in motion.

This thread has been closed by the system or the community team. You may vote for any posts you find helpful, or search the Community for additional answers.

The iPhone time goes backwards: a time warp maybe?

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple Account.