TCX issues with Training Peaks

[pcolby]

From http://www.dcrainmaker.com/2014/06/polar-v800-depth-review.html#comment-713639

In TP, Strange things occured in the graphs when laps are included, creating a new tcx using hrm and gpx solve this issue but the map is no longer available.

[blondin21]

Hi

Please find a link to a picture showing the issue:
with the tcx provided by bipolar: http://i39.servimg.com/u/f39/18/89/18/86/tp110.jpg

Best, Blondin

[pcolby]

[pcolby]

Thanks Blondin,

Just quickly, based on flow.polar.com's view, would say that the heart rate / pace graph looks like full 1hr crunched down to the size in the picture, or does it look more like a subset of the heart rate / pace graph from somewhere within the run?

Thanks.

[blondin21]

Hi Paul
TP link: http://tpks.ws/FR2j and Flow link: https://flow.polar.com/training/analysis/23855269

The duration, distance and everything appeared accurate. There sis onlye the graph thatshow 6 hour without any information at all nor position in the map. I don't why, but it rememberd me an issue I had with polar converter when converting files from my RC3. When manual laps are present, there is sometime strange issues, as if all lap times and cumulataive times were taken into account leading to an unrealistic duration. I haven't done the computation, bu maybe the time period without any informatio is a kind of sum of all the split time available in the file.

Perhaps it's also an issue related directly to TP, since the file is perfectly analysed and pictured by Strava.

Best,
Blondin

[pcolby]

Thanks Blondin, that info is really helpful.

I'll start looking into this one in the next day or two... looks like an interesting one.

[pcolby]

There sis onlye the graph thatshow 6 hour without any information

Interestingly, I see the exact same 6 hours before the data. I was expecting something different, on the assumption that we're in two different timezones (I'm +10 at the moment).

This definitely looks like a silly bug in TrainingPeaks, but I won't point fingers just yet...

[pcolby]

creating a new tcx using hrm and gpx solve this issue but the map is no longer available.

Actually, you can just upload the GPX in TP directly - map in tact, etc.

So this is a TCX-only issue. Still looks like TP's issue, but I'm looking deeper...

[pcolby]

What's the bet its somehow related to this:

[pcolby]

Yikes. TP is pretty 💩 when it comes to dates, timestamps and time zones 😦

[pcolby]

If TCX presents a timestamp in UTC, and my user settings are set to UTC, then the site still gets the activity time wrong, but reducing it by 6 hours. Clearly TP has something wrong in its TCX import code.

[pcolby]

Ok, so these fail miserably:

• 2014-08-25T19:49:59+10:00
• 2014-08-25T19:49:59+00:00

But this works fine:

• 2014-08-25T19:49:59Z

The TCX schema says these should all be xsd:dateTime, which allows the specification of time zones like all of the examples above (http://www.w3.org/TR/xmlschema-2/#dateTime-timezones).

So, TP is wrong 😦

The only workaround (ie not waiting for TP to fix their code), would be to force all TCX data points to UTC 😦

I'll probably just have to add that as a configurable option.

[profanum429]

I think it might be the same issue SportTracks 3 has with dates. I've only been able to get ST3.1 on my laptop to accept TCX files with the Zulu offset instead of the +XX:XX offsets. I modified trainingsession.cpp with a toTimeSpec(Qt::OffsetFromUTC) call whenever a date is written to a TCX to workout the ST3 bug. It seems to keep the correct time. Never brought it up since the spec allows for both types and considered it a ST3 bug and not a Bipolar bug.

[pcolby]

Thanks for the info @profanum429 :)

Ok, so I'll add an option to use either UTC or the watch's data time zone. Probably default it to UTC since there's probably more sites / programs out there with this same bug (and Strava doesn't care either way, as long the conversion is right). It just means then, that it will be affected by the quality of the host's DST data... always good to avoid if possible.

[pcolby]

In thinking about it a bit more, I bet what's happening is: When TP sees a timezone it doesn't recognise (ie anything other than Zulu?), then the code that parses the Lap@StartTime attribute defaults to UTC, but the code that parses the Trackpoint/Time elements defaults to Denver/UTC-06:00 (ie the same default the user settings uses, and probably where TP is based). That would explain the 6 hour gap at start of the samples, as opposed to simply shifting the entire data set around by a few hours.

I have a support ticket open with TP, so I'll see what the have to say, but I'm not expecting much help.

[pcolby]

Just FYI, I've had a dialog re this over TrainingPeaks support. The summary being:

Would it be onerous to ask you to do the timestamps in Zulu time? I don't know if this is a change that anyone here is willing to undertake as we get quite a large number of .tcx files from Garmin without any parsing issues.

In other words, TP's software can't handle non-Zulu time (which is a defect, of course), but they're not likely to prioritise fixing it any time soon, since most other people (ie Garmin users) use Zulu time anyway.

[pcolby]

I'll add an option to use either UTC or the watch's data time zone. Probably default it to UTC since there's probably more sites / programs out there with this same bug

Done. Included in release 0.3.1 - https://github.com/pcolby/bipolar/releases/tag/v0.3.1

Cheers.