Import error with GPX (and KML) files from "Zeopoxa cycling"

[benjif]

Describe the bug
An error occurs when I try to import a GPX (or KML) file from the Zeopoxa Cycling app.

Presumably the KML import error is related to #245 (Zeopoxa's KML exports use LineString). I'm not sure what element causes the error with GPX files.

To Reproduce

1. Export your track from Zeopoxa Cycling (I've included samples).
2. Import the track with OpenTracks.
3. OpenTracks shows an error.

Here is a sample GPX file
Here is a sample KML file

Technical information

• Device: [e.g. Samsung Galaxy S8 (SM-G950U)]
• OS: [e.g. Android 9]
• Version [e.g. v3.7.4]

[rgmf]

The datetimes in the GPX file don't have time zone information or Z if they use UTC. If you add Z to all datetime in the file the it's imported correctly.

OpenTracks expect datetime as defined at https://www.w3.org/TR/xmlschema-2/#dateTime

[dennisguse]

@rgmf Thanks for the quick analysis.

I introduced this behavior in 32070a0.
For API26+, I use ISO_DATE_FORMAT to parse dates, but this requires the Z.
On older platforms the original parsing code is still used (does not require a Z).
It was an attempt to cleanup a pretty nasty manual parsing function.

But I did not check what the actual KML/GPX specification says about this....
So, we can either revert this or figure out how to use the API26+ for an optional Z.

[rgmf]

But I did not check what the actual KML/GPX specification says about this....

According to https://www.topografix.com/gpx_manual.asp#time "Creation/modification timestamp for element. Date and time in are in Univeral Coordinated Time (UTC), not local time! Conforms to ISO 8601 specification for date/time representation. Fractional seconds are allowed for millisecond timing in tracklogs."

In OpenTracks, parseTime in StringUtils expect a ISO 8601 time, at least in API26+.

I think it's okay or Am I missing something?

[benjif]

According to https://www.topografix.com/gpx_manual.asp#time "Creation/modification timestamp for element. Date and time in are in Univeral Coordinated Time (UTC), not local time! Conforms to ISO 8601 specification for date/time representation. Fractional seconds are allowed for millisecond timing in tracklogs."

It appears that GPX files correctly require the "Z" suffix for UTC (which Zeopoxa Cycling erroneously excluded). Closing this, but feel free to reopen if you want to be lenient with this parsing case.

[dennisguse]

@benjif You are right, we really can be lenient in this case.
Thanks for reporting this issue :)
Fix will be in the next release.