The iPhone time goes backwards: a time warp maybe?

Question

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?

Answer 1

Thanks a lot Learning Annex Certified, that solved my problem.
Indeed machabsolutetime() 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 machabsolutetime() 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 machabsolutetime() would have been available on Win98.