Importing GPX/KML ignores timestamps with timeoffset

[dennisguse]

Description

As v3.2.4, OpenTracks exports timestamps with time offset at recording time.
Timestamps are exported as xsd:dateTime as definde by KML and GPX: https://www.topografix.com/gpx/1/1/
Examples:

• Zulu time: 2021-10-05T17:28:15.948Z`
• With time offset: 2021-12-19T14:44:19.308+01:00

OSMAnd only seems to support timestamps with Zulu time.
Please add full support for xsd:dateTime.

We got the report here: OpenTracksApp/OpenTracks#1370

How to reproduce?

Import a GPX/KML with time offset.
Track will be shown, time-related statistics will be missing.

Your Environment

OsmAnd Version: v4.1.11

[sonora]

While it is no big deal to expand our parser, I am not entirely convinced it is really in the topografix standard?!

ISO 8601 specifies 3 possible options for time zone designators, called:

1. "Local time (unqualified)" (14:45:15)
2. "Coordinated Universal Time (UTC)" (14:45:15Z)
3. "Time offsets from UTC" (14:45:15+x:00)

And http://www.topografix.com/gpx.asp states: "Date and time in are in Universal Coordinated Time (UTC), not local time! Conforms to ISO 8601 specification for date/time representation."

By saying "Universal Coordinated Time (UTC)" they literally reference option 2 above as worded in ISO 8601.

[dennisguse]

thanks for the quick feedback!

My argument is that 2. and 3. are actually the same: 14:45:15Z == 14:45:15+00:00.
If the time zone offset is different than 00:00, it actually provides more information.
Technically, the timestamp is in UTC plus/minus time offset: https://en.wikipedia.org/wiki/ISO_8601#Time_offsets_from_UTC

This is how it is handled by KML2.3: https://docs.opengeospatial.org/is/12-007r2/12-007r2.html

[vshcherb]

@sonora we can change here https://github.com/osmandapp/OsmAnd/blob/master/OsmAnd-java/src/main/java/net/osmand/GPXUtilities.java#L78 seems to work but needs to be tested on different phones

private static final String GPX_TIME_PATTERN = "yyyy-MM-dd'T'HH:mm:ssXXX";
private static final String GPX_TIME_MILLIS_PATTERN = "yyyy-MM-dd'T'HH:mm:ss.SSSXXX";

[sonora]

We have (public) parseTime and formatTime methods in GPXUtilities.java. If anything, I would not change it in general (i.e. for GPX writing), since it is clearly the standard. Could think about adding this to our parser so these kind of tracks are correctly understood when read.

[vshcherb]

Yes, you are right, we shouldn't change writing though as I see

"yyyy-MM-dd'T'HH:mm:ssXXX"
it parses correctly both dates

System.out.println(new Date(parseTime("2009-10-17T18:37:34Z")));
System.out.println(new Date(parseTime("2009-10-17T18:37:34.33Z")));
System.out.println(new Date(parseTime("2009-10-17T18:37:34+01:00")));

[sonora]

Looks like we "half" support it (I just tried an OsmAnd-recorded file, replacing all "Z<" by e.g. "+02:00<"):

• The file is read ok
• On the analysis graphs you can plot things vs. time (relative to the recording start), and this works(!) both on the Track tab or using "Analyze on map".
• But e.g. the track data shows no "time span" or "time in motion" value, and using "Analyze by intervals" you get no time-related values.

So it's a partial flaw we could fix, spending some effort to check where things work and where they fail...

[vshcherb]

did you change it? I think it's not broken totally but this format

"yyyy-MM-dd'T'HH:mm:ssXXX" would support both

[dennisguse]

Would recommend to use this as it is more descriptive (and is less custom): TemporalAccessor t = DateTimeFormatter.ISO_DATE_TIME.parseBest(xmlDateTime, ZonedDateTime::from, LocalDateTime::from);

See: https://github.com/OpenTracksApp/OpenTracks/blob/3075f4010f946cbc1595e0c34686c5fc0b752176/src/main/java/de/dennisguse/opentracks/util/StringUtils.java#L240

[sonora]

Well fixed as is from what I see - works flawless for all tests I can think of.👍