CMLogItem.timestamp: which clock is it on, and how to convert to AVCaptureSession.synchronizationClock / host time?

We need to determine whether a pressure measurement's event time falls inside an application operation bounded by a supported monotonic clock. Could Apple clarify the supported contract for CMAltitudeData.timestamp on iOS?

The official contract is what the timestamp documentation says:

"The timestamp is the amount of time in seconds since the device booted."

...which, as you've noted, isn't all that strong. Informally, I believe it's actually mach_absolute_time, converted to a double of seconds.

Does CMAltitudeData.timestamp use the same epoch and rate as mach_absolute_time(),

We actually have relatively few time sources, with mach_absolute_time and mach_continuous_time being the primary underlying clocks.

If only some are compatible, which ones?

DispatchTime.uptimeNanoseconds or ProcessInfo.systemUptime?

Both of those derive from mach_absolute_time.

CACurrentMediaTime(),

I think this does too, but its implementation is a bit more complicated.

Does it advance or pause during device sleep, device lock, application suspension, and background execution? In particular, are its sleep/suspension semantics guaranteed to match any of the clocks above?

I believe all of the clocks above will behave identically.

Is there a supported API for converting CMLogItem.timestamp to a host CMClock/Mach time, or for sampling “now” in the exact same clock domain used by CMAltitudeData.timestamp?

The main issue here is how "accurate" you think the value will be. If you're trying to correlate events within a second or so, then the comparison is relatively straightforward; however, the more precise you try and make that comparison, the more "philosophical" this question becomes. Our altimeter isn't doing its own timestamping, so below a certain threshold, things like event processing jitter inside Locationd start having a significant effect.

Are the answers contractual across supported iPhone hardware and iOS releases, or are they implementation details that applications should not rely on?

Both? Strictly speaking, they're implementation details that could theoretically change at any time. Having said that, the implementation hasn't changed since iOS 4 (when CoreMotion was introduced), and I don't see any particular reason why it would.

If direct comparison is not supported, what Apple-supported clock or conversion mechanism should an application use to compare a CMAltitudeData event time with two application-side monotonic operation boundaries?

The paranoid implementation here would be for your app to regularly correlate the times returned by the various clock sources you were trying to correlate. Sampling time differences means the times would never align; however, I think you'd find that the actual divergence was always within a fairly narrow band, assuming you were careful not to introduce your own divergence [1].

[1] The main issue here is that thread activity can delay event delivery, which would push CMAltitudeData "back" in time. However, as long as you’re only trying to correlate user-relevant wall times, that divergence shouldn't be large enough to matter.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware