Is Date/timestamp reported as part of CLLocation a time in UTC?

I am comparing results from LocationsServices (particularly speed) with velocity reported by my ublox NEO-M9N receiver. I am 99% certain that I have correctly obtained the UTC time associated with each fix/speed from the receiver. I then compare that time series with the time series of speeds vs time from Core Location services. To align the 2, I must apply a time scale factor of ~ 0.6% to one to allow good alignment between the 2 time series. This is saying that time from Core Location is progressing at a different rate than the UTC time as reported by the GPS receiver.

The Date/timestamp reported as part of CLLocations looks like a UTC. But, right now, I can't find anything definitive that it is a UTC. There are different flavors of UTC; the Naval Observatory has one flavor and NIST has another.

Can anyone point me to definitive documentation clear stating what time is reported in the Date/timestamp in the CLLocation reported by LocationServices? I am hard pressed to believe that 2 versions of UTC could be so different.

Thanks

Replies

I don't think you'll find good documentation.

I do recall some previous discussions about this. Note that while GPS locations could in principle have accurate timestamps from the GPS receiver, in practice Core Location also includes locations from other sources and for those iOS probably has to use its own internal clock. So maybe all locations get timestamps from the internal clock. And where does the iOS clock get its reference time from? None of this is documented.

I suggest trying to avoid writing any code that relies on these timestamps.

 time from Core Location is progressing at a different rate than the UTC time as reported by the GPS receiver.

A fixed offset would be easier to understand than "progressing at a different rate"! Over how long are you measuring this? The "different flavours of UTC" that you refer to can't possibly progress at 0.6% different rates!

I agree completely endecopt. I did have to also shift IOS time by ~ 1sec. I did not reported that in my original post because I too could rationalize such an offset. But, 0.6% is 6000ppm! That kind of accuracy is the kind that you find on really poor oscillator. Unless I have made some kind of mistake in my analysis, I conclude that the time associated with the position/location can NOT be a UTC time.

Great question, thanks for posting! The discussion is also insightful.

iOS devices set their clocks and calibrate their oscillators from a blend of several different trusted time sources, including GPS, depending on availability. One second of elapsed device time is a best-effort alignment to one second of elapsed UTC time. If device time is set automatically, then it will be a best-effort alignment to UTC. Note, however, that a device owner may choose to set a custom time at Settings -> General -> Date & Time -> Set Automatically (turn off).

The timestamp attached to a CLLocation object will be the device’s best estimate of the time of validity of the associated location information. endecopt is correct that CLLocation timestamp accuracy may vary depending on the underlying technology used to produce the location. The 6,000 ppm oscillator drift you observed in your data is not expected though. If you’d like some help with that, you can file a report through Feedback Assistant so we can take a look.