Fixed

Moves timezone patch

Workout start and end times are recorded by the equipment as the local time on the clock at the
facility. Until now the API labelled them with the time zone held on the member's Myzone profile,
and with +00:00 whenever that was not set. The clock reading was right; the offset frequently was
not, so the timestamp resolved to the wrong moment in time.

Each workout is now labelled with the offset that was genuinely in force where and when it was
recorded, taken from the workout record itself.

APIs affeced

Retrieve a user's move

Retrieve a user's move history

Get a report for a specified move

What you may need to change

  • Check your day boundaries. If you have been sending a facility's local midnight labelled Z
    to pull one calendar day, send that midnight with the facility's offset for that date instead —
    remembering the offset changes across a daylight saving transition. If you have been sending
    genuine instants, such as "the last 24 hours", your window was previously shifted by the facility
    offset and is now correct: nothing to change.
  • Parse the offset in the response rather than assume it. Anything that matches on +00:00 or Z, trims the last six characters, or appends a Z of its own will now be wrong. Two workouts on the same account can legitimately carry different offsets, so the offset cannot be looked up once per member and Reused.
  • Re-sync workout times you have already stored. If you converted start to UTC or to an epoch value and stored it, those stored moments are out by the facility's offset. moveId is unchanged, so re-fetching and matching on moveId corrects them in place; de-duplicating on a timestamp instead will create a second copy of every workout.