Skip to content

[board] Measure session, view and timed event durations on a monotonic clock - #491

Draft
arifBurakDemiray wants to merge 1 commit into
stagingfrom
board/wall-clock-duration-monotonic-countly-sdk-ios
Draft

arifBurakDemiray wants to merge 1 commit into
stagingfrom
board/wall-clock-duration-monotonic-countly-sdk-ios

Conversation

@arifBurakDemiray

Copy link
Copy Markdown
Member

Board card C-111: Session/view/event durations use wall-clock differences on Android, iOS and Web; C++ fixed this on 10-17 (ios). Part 2 of 3 of C-108.

Source: https://test-deniz.count.ly/e6a1f3cbb85c4db89d3c7d5b9ab739ab1e99969785c99aec6347327c1ac7d8a5/2026-10-19.html (reference fix: Countly/countly-sdk-cpp#161)

What breaks without it

Session, view and timed event durations are differences of NSDate.date.timeIntervalSince1970 readings. When the user or the network time sync moves the system clock while one of them is running, the duration moves with it: backwards gives a negative or too short session_duration / dur, forwards inflates engagement. Reasoned from the code, not reproduced on a device.

What changed

  • New internal CountlyCommon.monotonicTime: seconds from clock_gettime_nsec_np(CLOCK_MONOTONIC_RAW).
  • Session: lastSessionStartTime and sessionLengthInSeconds read it.
  • Views: CountlyViewData.viewStartTime and duration read it (start, pause, resume).
  • Timed events: startEvent: also stores monotonicStartTime on the started CountlyEvent (in memory only, not encoded or sent); endEvent: takes the duration from it.
  • Every timestamp sent to the server stays on the wall clock, as in the C++ fix.
  • CHANGELOG entry under a new ## XX.XX.XX (26.8.0 is released).

Choice for the reviewer: which monotonic clock

The card suggests CACurrentMediaTime/systemUptime. Both stop while the device sleeps, so time asleep would drop out of a duration that the wall clock counts today (a timed event or a manual session spanning a sleep, or a Mac that sleeps with the app in front). CLOCK_MONOTONIC_RAW keeps counting through sleep and is what libc++'s std::chrono::steady_clock reads on Apple platforms, so this matches the C++ SDK. Checked on a Mac about 10 days after boot: CLOCK_MONOTONIC_RAW = steady_clock = 850,468 s, CLOCK_UPTIME_RAW = 378,474 s. Available from iOS 10 / macOS 10.12 / tvOS 10 / watchOS 3, so the minimum versions do not change.

Android (C-110) and Web (C-112) have no PR yet, so this could not be matched against the Android reference.

Verified

  • swift build (macOS) compiles with no new warnings.
  • iOS 16 Pro simulator: CountlyViewTrackingTests and CountlyViewForegroundBackgroundTests 27/27 pass (they assert view durations).
  • CountlyUserProfileTests (asserts session_duration) and the log gathering test that starts and ends a timed event: 26/27 pass. test_210_CNR_M timed out once waiting for a main-queue timer during the full class run; it passes on its own both on this branch and on staging, so it looks timing-dependent.

Not verified

  • A system clock change during a session, view or timed event: there is no seam to fake the clock, so this is reviewed in the code only, as in the C++ PR.
  • tvOS, watchOS and visionOS builds, and the full test suite.
  • timeSinceLaunch (crash _run, content initial delay) also uses the wall clock; it is outside this card and left unchanged.

🤖 Generated with Claude Code

…lock

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant