Activity.Info.elapsedTime erroneously includes time between when the activity is stopped and when it is saved.

I have a simple data field in which I get Activity.info.elapsedTime in the compute() method and use it in calculations. In the end I need the elapsed time between the start of the activity and the end of the activity when it is stopped, and that time is used to calculate a value saved as a FIT session data value.

However, it looks like the last value of Activity.info.elapsedTime that I get includes the time between when the activity is stopped and when it is saved.

Is this a bug? Is there any way to get the elapsed time and not include the time between the stop and the save?

jim_m_58 over 4 years ago

This is correct, as it's the time from when recording was first started, including pauses, etc. If you want the time actually recorded time, use timerTime

flowstate over 4 years ago

TL;DR I don't think it's a bug, but it is unavoidably inconsistent with what's shown *after the fact* in both Garmin and Strava. There is a way to get the elapsed time that you want, for the purposes of recording a FIT session value -- just sample the elapsed time in DataField.onTimerStop().

I think the point of contention here is whether Activity.info.elapsedTime should include the time between the final pause and when the activity is saved. After the fact, both Garmin and Strava actually exclude this final chunk of paused time.

For example, I tried the following experiment with a Run activity (to confirm what I've seen in the past):

- Start

- Record 5 seconds

- Pause 3 seconds

- Record 3 seconds

- Pause 4 seconds

- Save

Both Garmin Connect and Strava showed the activity time as 8 seconds and the elapsed time as 11 seconds. In other words, the final 5 second chunk of paused time (between the final pause and saving the activity) was not included. I can see why this makes sense for users, as there might be a long period of time between the final pause and saving the activity, if you forgot to press Save for some reason.

However, when I looked at the native elapsed time data field on the watch, it continued to count up past 11 seconds, until I actually saved the activity. This makes sense: it's impossible for Activity.info.elapsedTime to exclude the time between the final pause and when the activity is saved, because it's a measure that's constantly updated in real time, and doing so would require the watch to look into the future to see if the user is going to start the activity again before saving it.

For this specific use case, it seems the following approach could work:

1) In the first call to DataField.onTimerStart(), record the time T_start. This is the activity start time.

2) In every call to DataField.onTimerStop(), record the time T_now, calculate the elapsed time T_now - T_start, calculate your derived metric value, and write it to the FIT session field.

Since it's a session data value, only the final value you write will be used.

EDIT or even more simply:

- In every call to DataField.onTimerStop(), use the current value of ActivityInfo.elapsedTime, calculate your derived metric value, and write it to the FIT session field.