For Connect IQ SDK 9.2.0 on macOS with the fēnix 7X simulator target, what documented relationship connects app UTC observations to timestamps written by ActivityRecording into native FIT timer Event messages?
In preserved synthetic runs, app-side probes used `Time.now()` and `Time.getCurrentTime()` with DEFAULT and RTC selections around start, pause, resume and final-stop/save operations. Within each sampled bundle these app integer readings agreed. After only the standard FIT-to-Unix epoch conversion, native timer-event integers matched the surrounding app integers in two direct-native reference conditions but were one integer second higher in a separate recorder condition. A later long synthetic recording retained a strict final-event comparison failure. No offset or tolerance was fitted to make these results pass.
The runs were separate simulator conditions, not a controlled proof of which component caused the difference. Host log-arrival times include buffering/transport and are not native acquisition times. Native duration scalars and absolute Event timestamps are separate quantities; a supported elapsed/timer duration does not resolve absolute clock alignment.
1. Which clock supplies native FIT Event `timestamp` and Session `start_time` in the simulator, and how does it relate to the app's DEFAULT/RTC clocks and host wall time? What differs on physical devices?
2. At what point are start/stop/lap timestamps acquired, and what truncation, rounding or other quantization rule is applied to integer-second FIT fields?
3. Is a one-integer-second difference in this scenario documented or known for particular versions? What evidence distinguishes quantization, acquisition latency and clock-source differences?
4. What supported prospective comparison method and justified bounds should an app use? Please specify assumptions rather than a blanket tolerance or post-hoc clock shift.
Reference: [Toybox.Time](developer.garmin.com/.../Time.html). This question is limited to native activity-event/app UTC semantics, not motion-sample clock correlation. We have not established a simulator-only cause or a physical-watch defect, and are not proposing changes to recorded timestamps.