Bugzilla

:chutten Agree 100% about the different sources of timing, and the need to cross reference them.  However, I'm not sure this will get you what we want in that regard.

The current `glean.baseline.duration` value measures the "session length", or the time the browser was in foreground.

`start_time` is the start of the ping lifetime, which in the case of the baseline ping actually begins right *after* the browser goes to background, and the `end_time` is set the *next* time the browser goes to background.

I'm not writing this to be pedantic -- I too was confused by this when I recently tried to see if the discrepancies between these spans could be used to see patterns in why duration was sometimes NULL (bug 1525600).

Beyond that, even if we did change the definition of `duration` to match that of `start_time`/`end_time` and be about ping lifetime, it would be difficult to use a monotonic timer for that, since currently a metrics ping (sent at most one a day) could have a lifetime that extends across reboots, and the monotonic timer is reset across reboots.  So we would be forced to using the system clock for that anyway (with all of its known problems) or using some sort of network time as I think as been discussed elsewhere, with all of its complexity.

:chutten Agree 100% about the different sources of timing, and the need to cross reference them.  However, I'm not sure this will get us what we want in that regard.

The current `glean.baseline.duration` value measures the "session length", or the time the browser was in foreground.

`start_time` is the start of the ping lifetime, which in the case of the baseline ping actually begins right *after* the browser goes to background, and the `end_time` is set the *next* time the browser goes to background.

I'm not writing this to be pedantic -- I too was confused by this when I recently tried to see if the discrepancies between these spans could be used to see patterns in why duration was sometimes NULL (bug 1525600).

Beyond that, even if we did change the definition of `duration` to match that of `start_time`/`end_time` and be about ping lifetime, it would be difficult to use a monotonic timer for that, since currently a metrics ping (sent at most one a day) could have a lifetime that extends across reboots, and the monotonic timer is reset across reboots.  So we would be forced to using the system clock for that anyway (with all of its known problems) or using some sort of network time as I think as been discussed elsewhere, with all of its complexity.