DATETIME: Wrong timezone for UTC in attribute table

[pathmapper]

What is the bug or the crash?

Z for Zero timezone (UTC) is ignored, instead local timezone is displayed in attribute table.

Tested for GPKG (type DATETIME) and GeoJSON files and also for a WFS layer:

"timestamp": "2022-04-13T12:05:23Z"

results e.g. in

So in this example the displayed time is wrong by 2 hours.

Steps to reproduce the issue

1. Extract and inspect test data (GPKG and GeoJSON): test_data.zip
2. Drag'n'drop files into QGIS
3. Open attribute table
4. See error: local timezone is displayed but there shoud be zero timezone (UTC)

Versions

master (cca3562) on Ubuntu

and

3.24.2 on Windows

QGIS-Version	3.24.2-Tisler	QGIS-Codeversion	13c1a02
Qt-Version	5.15.2
Python-Version	3.9.5
GDAL-Version	3.4.2
PROJ-Version	9.0.0
EPSG-Registraturdatenbankversion	v10.054 (2022-02-13)
GEOS-Version	3.10.2-CAPI-1.16.0
SQLite-Version	3.38.1
PDAL-Version	2.3.0
PostgreSQL-Client-Version	unknown
SpatiaLite-Version	5.0.1
QWT-Version	6.1.3
QScintilla2-Version	2.11.5
BS-Version	Windows 10 Version 1809
Aktive Python-Erweiterungen
db_manager	0.1.20
grassprovider	2.12.99
MetaSearch	0.3.6
processing	2.12.99
sagaprovider	2.12.99

Supported QGIS version

• I'm running a supported QGIS version according to the roadmap.

New profile

• I tried with a new QGIS profile

Additional context

If the layer is exported, e.g. to GeoJSON, the Z from the timestamp is missing:

Before import::
2022-04-13T12:05:23Z

After export:
2022-04-13T12:05:23

---

Related SE post:

• https://gis.stackexchange.com/questions/281106/qgis-automatically-converts-utc-date-time-to-local

[pathmapper]

Looks like the timezone shown for DateTime fields in the attribute table and the identify features tool is currently the OS timezone and has nothing to do with the data timezone.

E.g. for Windows, if you set the OS timzone in the Windows seetings to UTC-10 - Hawaii

for the test data provided above the timezone shown in the attribute table and identify feature result is also Hawaii:

[pathmapper]

Related:

• OGR utils loses millisecond and timezone information when parsing GeoJSON features #44160
• [ogr] Correctly set timezone spec on datetime values #44627
• Show time zone information for datetime field values and datetime expression results #44626

[heidivanparys]

This is really a problem for GeoPackage, as GeoPackage files must have the timestamps as UTC time according to the GeoPackage standard, see also opengeospatial/geopackage#530, especially this comment: opengeospatial/geopackage#530 (comment):

[…] the OAB recommends that standards conform to the UTC time as specified in both OWS Common and the existing GeoPackage text […]

So currently I have the option between

• creating GeoPackage files where timestamps have a UTC offset, which are shown correctly in QGIS but are not in accordance with the spec;
• or creating GeoPackage files where timestamps are in Zulu time, in accordance with the spec, but that are shown incorrectly in QGIS.

[pathmapper]

creating GeoPackage files where timestamps have a UTC offset, which are shown correctly in QGIS but are not in accordance with the spec

Additionally this would work currently only if the UTC-offset matches the OS timzone - so it would be specific for the machine/settings you are using. For different settings and/or machine with different OS timezone, the offset would not match what is displayed in QGIS.

[heidivanparys]

For reference, related discussions on the QGIS developer mailinglist:

• QGIS Date, Time and TimeZones (thread 1)
• QGIS Date, Time and Time Zones (thread 2)

[drf5n]

Steps to reproduce the issue

1. Extract and inspect test data (GPKG and GeoJSON): test_data.zip
2. Drag'n'drop files into QGIS
3. Open attribute table
4. See error: local timezone is displayed but there shoud be zero timezone (UTC)

The test data in the github.com/qgis/QGIS/issues/48393 -- github.com/qgis/QGIS/files/8592150/test_data.zip -- has internal timestamps of 2022-04-13T12:05:23.000Z If those aren't treated as UTC time within QGIS, QGIS is wrong.