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.
