search

Maproom / qmapshack

Consumer grade GIS software
GNU General Public License v3.0
271 stars 63 forks source link

GPX track point timestamps in UTC are validated as local time #672

Open conclavia opened 3 months ago

conclavia commented 3 months ago

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.

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

Screenshot from 2024-03-25 17-13-10

Screenshot from 2024-03-25 16-31-03

Attachments

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

Tracebacks

comment: # (Add your backtrace below if you have one. If QMapshack crashes the fastest way to get help is a backtrace. For Linux see: https://github.com/Maproom/qmapshack/wiki/TroubleShooting#create-a-backtrace-of-a-crash-on-linux. For Windows it would need a debug build and running QMapshack in Visual Studio.)

Desktop

Additional context

mitxel-m commented 3 months ago

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

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.

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

UTC

Australia_Sidney

HTH. This seems to be a strange error.

kiozen commented 3 months ago

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

conclavia commented 3 months ago

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!