QGIS Time error: UTC = Australian Central Standard Time

[garrytre]

What is the bug or the crash?

QGIS version 3.26.3-Buenos Aires Ubuntu 20.04.6 LTS

I originally made a GPS waypoint approximately lunch time in central Australia.

In QGIS I import a gpx file with waypoint

2023-04-23T01:12:40Z

The resultant feature's attribute table has time:

23/4/23 01:12:40 (ACST)

So somewhere is an awareness that I live in Australian Central Standard Time, but the calculation hasn't been done to convert UTC to ACST.

Steps to reproduce the issue

Have a .gpx with as above Drag into QGIS look at attribute table

This is the text in the .gpx, copied from kwrite (text editor). Longer gpx files have the same prob.

<?xml version="1.0" encoding="UTF-8" standalone="no" ?>

Garmin International 2023-08-03T08:43:39Z 500.0000000 2023-04-23T01:12:40Z zcp >10 trees on Brachina Fm but only on road cutting, not on weathered surface. garrytre@bigpond.com >10 trees on Brachina Fm but only on road cutting, not on weathered surface. garrytre@bigpond.com Waypoint SymbolAndName 503.0000000 2023-04-23T01:08:20Z zcpPowerLine100m >10 trees on Brachina Fm but only on road cutting, not on weathered surface. Powerline 100meters away. garrytre@bigpond.com >10 trees on Brachina Fm but only on road cutting, not on weathered surface. Powerline 100meters away. garrytre@bigpond.com Waypoint SymbolAndName ### Versions QGIS version | 3.26.3-Buenos Aires | QGIS code revision | 65e4edfdad -- | -- | -- | -- Qt version | 5.12.8 Python version | 3.8.10 GDAL/OGR version | 3.0.4 PROJ version | 6.3.1 EPSG Registry database version | v9.8.6 (2020-01-22) Compiled against GEOS | 3.8.0-CAPI-1.13.1 | Running against GEOS | 3.8.0-CAPI-1.13.1 SQLite version | 3.31.1 PDAL version | 2.0.1 PostgreSQL client version | 12.12 (Ubuntu 12.12-0ubuntu0.20.04.1) SpatiaLite version | 4.3.0a QWT version | 6.1.4 QScintilla2 version | 2.11.2 OS version | Ubuntu 20.04.6 LTS   |   |   |   Active Python plugins valuetool | 3.0.15 quick_map_services | 0.19.33 MetaSearch | 0.3.6 processing | 2.12.99 grassprovider | 2.12.99 db_manager | 0.1.20 sagaprovider | 2.12.99 QGIS version 3.26.3-Buenos Aires QGIS code revision [65e4edfdad](https://github.com/qgis/QGIS/commit/65e4edfdad) Qt version 5.12.8 Python version 3.8.10 GDAL/OGR version 3.0.4 PROJ version 6.3.1 EPSG Registry database version v9.8.6 (2020-01-22) Compiled against GEOS 3.8.0-CAPI-1.13.1 Running against GEOS 3.8.0-CAPI-1.13.1 SQLite version 3.31.1 PDAL version 2.0.1 PostgreSQL client version 12.12 (Ubuntu 12.12-0ubuntu0.20.04.1) SpatiaLite version 4.3.0a QWT version 6.1.4 QScintilla2 version 2.11.2 OS version Ubuntu 20.04.6 LTS Active Python plugins valuetool 3.0.15 quick_map_services 0.19.33 MetaSearch 0.3.6 processing 2.12.99 grassprovider 2.12.99 db_manager 0.1.20 sagaprovider 2.12.99 ### Supported QGIS version - [X] I'm running a supported QGIS version according to [the roadmap](https://www.qgis.org/en/site/getinvolved/development/roadmap.html#release-schedule). ### New profile - [X] I tried with a new [QGIS profile](https://docs.qgis.org/latest/en/docs/user_manual/introduction/qgis_configuration.html#working-with-user-profiles) ### Additional context I originally put this in https://gis.stackexchange.com/questions/464570/qgis-time-error-utc-australian-central-standard-time?noredirect=1#comment758644_464570 and was advised to put it here.

[agiudiceandrea]

@garrytre, thanks for reporting. QGIS 3.26 is no longer supported: please try if the issue does occur also using a supported QGIS version according to the roadmap as requested in the issue report form (you can try the Flatpak version, since QGIS 3.28 and 3.32 are not available on Ubuntu 20.04). Could you please provide a sample gpx file attaching it as a zipped file to this issue report? Have you tried to add the gpx flle in QGIS using the Data Source Manager -> GPS dialog window instead of dragging and dropping it?

[garrytre]

agiudiceandrea thank you for your attention

I can't install the flatpak, nor a later version of QGIS. I'll have to wait for ubuntu24.04 plus whatever latest QGIS.

Not sure if there's any point investigating my old version, but you've asked, so here goes.

Below is the zipped gpx Codon_pyr_2023-04-25.gpx.zip

Have you tried to add the gpx flle in QGIS using the Data Source Manager -> GPS dialog window instead of dragging and dropping it?

Yes, really interesting. Two screendumps show that the method of importing produces different results. Drag-n-drop has about 30 fields, DataSourceManager has 6, NOT including time.

Anyway, thanks again, and I'll have to put this off for another day.

[agiudiceandrea]

@garrytre, using QGIS 3.28 on Windows (from OSGeo4W, with GDAL 3.7) the time is correctly displayed in the attribute table (my system tz is currently UTC+2 CEST):

[garrytre]

Yes but that's not the point. In your screen dump the time is 01:02:24 (UTC), which is what the original gpx file had, as z. That's correct. But my attrib table says 01:02:24 (ACST), ie the UTC time but labelled as ACST.

But anyway, if it's a problem with an old version, maybe not a newer version, and it isn't too much of a problem for me, and I'll eventually get a QGIS update, I'm happy to drop it. Call it solved?

from drag-n-drop

But I'm still fascinated by the different resultant fields depending on whether I drag-n-drop, or I do a DataSourceManager import. Apparently not a bug, but I'm now aware of it, ie if I do a DataSourceManager import, then I loose time + other fields. Something to watch out for.

Thank you.

[agiudiceandrea]

Yes but that's not the point. In your screen dump the time is 01:02:24 (UTC), which is what the original gpx file had, as z. That's correct. But my attrib table says 01:02:24 (ACST), ie the UTC time but labelled as ACST. But anyway, if it's a problem with an old version, maybe not a newer version, and it isn't too much of a problem for me, and I'll eventually get a QGIS update, I'm happy to drop it. Call it solved?

I'm closing this issue report since the issue doesn't occur using a currently supported version of QGIS and a recent version of the GDAL library (which is responsible of parsing the GPX file when imported using drag&drop or the Data Source Manager -> Vector dialog window) on Windows. Feel free to reopen this issue report if you verify that the issue does occur on your Ubuntu Linux system using a currently supported version of QGIS.

But I'm still fascinated by the different resultant fields depending on whether I drag-n-drop, or I do a DataSourceManager import. Apparently not a bug, but I'm now aware of it, ie if I do a DataSourceManager import, then I loose time + other fields. Something to watch out for.

The Data Source Manager -> GPS dialog window uses an internal data provider to parse the GPX file instead of using the GDAL library to parse it. I've filed an issue report about such bug: https://github.com/qgis/QGIS/issues/54119.

[agiudiceandrea]

@garrytre, the issue about the loose of the "time" field when you import the GPX layer in QGIS using the Data Source Manager -> GPS dialog window has been fixed with PR https://github.com/qgis/QGIS/pull/54632.