Incorrect timezone handling for import/export GPX

[qwerty287]

Is your feature request related to a problem? Please describe. I'm always frustrated when I import tracks that do not contain proper timezone information. The times are then interpreted as CE(S)T (my system’s timezone) while they actually use UTC.

Describe the solution you'd like A setting that allows me to set UTC as default timezone for imports.

Describe alternatives you've considered Changing the GPX file to contain proper dates.

Additional context This usually happens when importing from komoot.

An example timestamp: 2022-06-25T14:58:37.146Z. Opentracks imports this as 14:58 (as CEST), while it was actually recorded at 16:58 (the time as UTC converted to CEST).

[dennisguse]

You are right: we should not overwrite the timezone. If the file states UTC it is UTC end of story.

Anyhow: the exporting tool may include it; so I would recommend contacting Komoot and requesting this feature.

[qwerty287]

While informing myself more about ISO-8601 to submit my report to komoot, I found out that the timestamp actually contains a timezone, OpenTracks doesn't handle it correctly. There's no issue at komoot. The Z in the end of the timestamp indicates that the timestamp is in UTC. It looks like OpenTracks just ignores it.

And actually, the only timezone GPX allows is UTC. OpenTracks just ignores this when exporting tracks: according to the timestamp, it's a UTC time, while it's a CEST timestamp. What you would have to fix here:

1. on import from GPX, timestamps are always UTC and must be converted to the local timezone of the device first, don't assume it's already the local timezone
2. when exporting, convert the time to a UTC time first

[dennisguse]

Almost.

GPX has timestamps as xsd:datetime (supports timezones). And yes, OpenTrack should only fallback to default timezone if none is present. If one is present (like Z) then we should take it. Still komoot could export the recording timezone as well instead of UTC only.

[dennisguse]

So... I just checked the code and we only set the timezone to UTC if it is missing. We do not fallback to device local timezone. Code is in StringUtils.parseTime(). Importing and exporting should lead to the same timestamp.

So, what is the actual problem?

[qwerty287]

It doesn't work. The timestamp is UTC but interpreted as CEST (system timezone). A Z as timezone is ISO 8601 means it is UTC (maybe Opentracks interprets this as "system timezone"?). The komoot GPX doesn't contain any timezone information, except the Z in the end of every timestamp (which means UTC). OpenTracks should value this as UTC and I'm fine :)

[dennisguse]

I am somehow confused. While importing we honor the timezone data from the timestamp and if not present use UTC.

Could it be that you mean that we do not show the timezone in the UI properly?

[qwerty287]

I don't think so. If I export a track with a wrong time, it has the time as shown in the UI (the wrong time).

[qwerty287]

While importing we honor the timezone data from the timestamp and if not present use UTC.

Then it looks like this doesn't work.

I can try to look at the code myself, but I'd be happy if you could give me a hint where I find the important files/lines.

[dennisguse]

Take a look at TrackImporter.setTrack(...) and the two classes that are calling it.

[dennisguse]

And ExportImportTest might be helpful for debugging.

[qwerty287]

Indeed the code looks good, this is confusing. But I tested it now with different timezones in the timestamps:

• 2022-06-25T13:49:43.672Z - this is the original (in UTC), this shows me, even if I'm in CEST, the time 13:49 while it should be 15:49.
• 2022-06-25T13:49:43.672+01:00 - +1, imported as 13:49 as well, while it should be 14:49
• 2022-06-25T13:49:43.672+02:00 - +2, imported correctly as system and timestamp are on the same zone

It looks like the timezone is ignored completely and it always uses the system's timezone. However, your code looks good - I don't know why it doesn't work. May I don't understand something here? The time that is shown in the UI, is this the time in the system's timezone or in the track's timezone? (If it is, I'm very sorry for the trouble. Then I'll ask komoot to user proper timezones on export.)

[dennisguse]

I added a test for GPX which imports a file (with timezone infos) and exports - and this shows that the timezone is not changed (also if it is UTC). That brings me to the question: are you referring to the time shown in the track list? There we don't show the timezone offset - I guess this is technically incorrect if the device timezone offset is different that the track, right?

Potential solutions:

• show timezone offset if it is different than the device timezone offset
• compute actual time (but that removes the advantage of storing the timezone offset itself: see #301)

Suggestions?

[qwerty287]

Yes, I referred to the time in the UI, what I also asked above already. I think that's the best solution. Maybe it would be nice to view the offset of the track to allow easier debugging, but otherwise this issue is fixed/not an issue.

[dennisguse]

We should show the timezone as it is otherwise confusing.