GPX track point timestamps in UTC are validated as local time

[conclavia]

Describe the bug

When loading a GPX file containing track points with timestamps in UTC (e.g. <time>2016-10-02T02:00:06Z</time>) these points are being validated by QMapShack as if the timestamps were in local time.

The attached GPX file (2016-10-02 - Cowan & Cockle Creeks (Ku-Ring-Gai NP).gpx) was recorded in Australia/Sydney on 2016-10-02. This was the date when Daylight Savings started, meaning Australia/Sydney went from AEST / UTC+1000 (Australian Eastern Standard Time) to AEDT / UTC+1100 (Australian Eastern Daylight Saving Time).

QMapShack is reporting that all timestamps from 2016-10-02T02:00:06Z to 2016-10-02T02:59:48Z are invalid. This appears to line up with the period in local time that did not exist due to the Daylight Savings transition, when clocks moved forward from 2am => 3am.

However, the timestamps in the GPX file are all recorded in UTC not local Sydney time. The timestamps that are shown as invalid represent the period from 1pm => 2pm local time. This is after the Daylight Savings transition had already happened, and so should be valid.

What have you done to circle down the problem?

I've compared the behaviour between v1.16.1 and v1.17.0/v1.17.1.

• v1.16.1 does not report any invalid timestamps in the file (expected behaviour)
• v1.17.0 and v1.17.1 both report the timestamps as invalid (bug)

I also noticed that in v1.16 the timezone is displayed in the timestamp when viewing the track points, while the timezone is not displayed in v1.17.

The bug appears to be present in v1.17 on both Linux (Ubuntu) and Windows.

Using View => Setup Timezone to toggle the timezone between UTC, Local, Automatic and a specific timezone (Australia/Sydney) does not affect the validation behaviour. The timestamps are correctly displayed in the selected timezone however the same points always shown as invalid.

To Reproduce

1. Go to 'File' => 'Load GIS Data'
2. Load the attached GPX file (2016-10-02 - Cowan & Cockle Creeks (Ku-Ring-Gai NP).gpx)
3. See 'Invalid points...' popup displayed
4. Click 'No'
5. Right click on loaded track and select 'Edit'
6. Select 'Points' tab
7. Scroll to points from 2016-10-02T02:00:00 onwards

Expected behavior

Timestamps that are recorded in UTC should be validated as UTC times, and so the points from 2016-10-02T02:00:06Z to 2016-10-02T02:59:48Z in the attached GPX file should not be considered invalid.

Screenshots

Attachments

2016-10-02 - Cowan & Cockle Creeks (Ku-Ring-Gai NP).zip

Tracebacks

Desktop

• OS: Ubuntu 23.10 and Windows 10
• QMapShack Version: 1.17.0 and 1.17.1
• Window Manager: GNOME

Additional context

[mitxel-m]

I have loaded the gpx file and I can't reproduce this error.
I have tried on

• QMS 1.17.1 on Linux Mint21 ( based on Ubuntu 22.04)
• QMS 1.17.1 on WIN 10 (not up to date)

I have also tried changing the time zone setting, checking UTC and Australia/Sidney. No error is displayed and the time for each point changes according to the selected time zone.

• with UTC, the starting point is shown as 2016/10/01 21:57
• with Australia/Sidney the starting point is shown as 2016/10/02 8:57 (this is UTC +11).

See also screenshots at point #1009 where the error occurs for @conclavia :

HTH. This seems to be a strange error.

[kiozen]

Tried it too. Even automatic timezone selection works as expected.

[conclavia]

Thank you @mitxel-m and @kiozen !

I've done some more experimenting to see if I can figure out why I am seeing different behaviour to both of you, and I think I can see what is happening. QMapShack seems to be validating the times in the track points using the timezone configured in the regional settings of the computer's operating system, regardless of what is selected under View => Setup Timezone in QMapShack.

I'm guessing the GPX file is showing as valid for both of you because you are located in a timezone that doesn't have a Daylight Savings Time transition during that same period (i.e. anywhere other than AEST/AEDT).

I tested this on Ubuntu 23.10:

1. Close all open projects using Workspace => Close all projects
2. Change the computer's timezone using the Ubuntu Date & Time settings from Australia/Sydney to Europe/London
3. Import the GPX file
4. All track points show as valid
5. Close all open projects using Workspace => Close all projects
6. Change the computer's timezone using the Ubuntu Date & Time settings from Europe/London to Australia/Sydney
7. Import the GPX file
8. Track points now show as invalid again

I'm only guessing, but is it possible that when the timestamps are loaded into a date/time value it is automatically interpreting it using the local timezone rather than UTC? I've had a look around the repo but am not very familiar with either C++ or the QMapShack codebase. If anyone could point me to where the validation of the GPX track point timestamps actually happens I'm happy to try and dig more into the issue.

Thanks!