gie3d
commented
12 months ago Reviewed.
Left 2 minor comments (just questions/suggestions, not requests for change).
I assume that the only problem was in the
cacademode (I see the changes only around this mode), right?Thanks for your effort. I think you can add yourself as contributor in
package.json. I guess @jimmykane won't have objections. 🙂
Yes, the main different between Summary First and Summary Last is the sequence of message and the timestamp. So that's why it's directly impact how this library can map parent-child relationship between record, length, lap and session (the cascade mode was created to have parent-child relation in its json). However the list mode doesn't care about that relation. That's why there is no change in list mode.
And another thing that worth mention here is the behavior of timestamp in session and lap is different between Summary First and Summary Last.
In this PR, I intentionally do nothing about it because the timestamp is the time when the data is created.
- Summary First the
timestampis similar tostart_time(since the summary record was created first, that's why it's equal tostart_time) - Summary Last, the
timestampisstart_time + elapsed_time(since the summary record was created last, that's why the timestamp is record as that)
krzysztof-cislo
jimmykane
Refer to the https://github.com/jimmykane/fit-parser/issues/31 issue and as Garmin will change the Fit file format (https://forums.garmin.com/developer/fit-sdk/b/news-announcements/posts/important-fit-activity-file-message-change) from Summary Last to Summary First on Dec 1st, 2023. I propose another way for
cascademode in order to support both Fit file summary format.