For an application supporting iOS 16 and later, is there a supported public API that exposes a monotonic timestamp for the original determination of a CLLocation, rather than the time it is delivered to CLLocationManagerDelegate? The requirement is to reject observations whose original acquisition age exceeds 10,000,000,000 ns at the final native transport-dispatch check. Exactly 10 seconds is allowed; 10 seconds plus 1 ns is rejected before conversion to milliseconds. This is an arithmetic boundary requirement, not an assumption that location measurements have nanosecond physical accuracy. CLLocation.timestamp is a Date for when the location was determined. Sampling a continuous monotonic clock in didUpdateLocations instead measures callback receipt. Cached observations, batched updates and delayed background delivery can separate those events. Does a public API provide either: A monotonic acquisition/determination timestamp associated with that same CLLocation; or A documented finite uncertainty bound and supported method for relating its Date timestamp to a sleep-inclusive monotonic clock at dispatch? How do the documented guarantees handle wall-clock adjustments between determination and delivery, device sleep, suspension, queued updates and process restarts? If a newer API supplies stronger evidence, what is its minimum supported iOS version? If neither mechanism is available, is there a supported request or delivery mode that establishes a documented lower bound on the original determination time and can reliably reject older cached observations? A recent callback or request by itself would not establish that relationship. I would appreciate documentation describing the guarantees, limitations or supported alternatives. I have not established that such a mechanism is impossible; this is a capability clarification, not a claim of a reproduced operating-system defect.

CLLocation acquisition time: supported monotonic timestamp or bounded age conversion on iOS 16+?

For an application supporting iOS 16 and later, is there a supported public API that exposes a monotonic timestamp for the original determination of a CLLocation, rather than the time it is delivered to CLLocationManagerDelegate?

The requirement is to reject observations whose original acquisition age exceeds 10,000,000,000 ns at the final native transport-dispatch check. Exactly 10 seconds is allowed; 10 seconds plus 1 ns is rejected before conversion to milliseconds. This is an arithmetic boundary requirement, not an assumption that location measurements have nanosecond physical accuracy.

CLLocation.timestamp is a Date for when the location was determined. Sampling a continuous monotonic clock in didUpdateLocations instead measures callback receipt. Cached observations, batched updates and delayed background delivery can separate those events.

Does a public API provide either:

A monotonic acquisition/determination timestamp associated with that same CLLocation; or
A documented finite uncertainty bound and supported method for relating its Date timestamp to a sleep-inclusive monotonic clock at dispatch?

How do the documented guarantees handle wall-clock adjustments between determination and delivery, device sleep, suspension, queued updates and process restarts? If a newer API supplies stronger evidence, what is its minimum supported iOS version?

If neither mechanism is available, is there a supported request or delivery mode that establishes a documented lower bound on the original determination time and can reliably reject older cached observations? A recent callback or request by itself would not establish that relationship.

I would appreciate documentation describing the guarantees, limitations or supported alternatives. I have not established that such a mechanism is impossible; this is a capability clarification, not a claim of a reproduced operating-system defect.