QGIS
QGIS copied to clipboard
qgis
DATETIME: Time zone is being changed in attribute table and source file
What is the bug or the crash?
I would like to report the issue with working with GeoJSON files in layer's editing mode.
After opening the Attribute Table and when the column is editable, the QGIS changes the value (the time zone ) of a record selected, just after clicking on it. After saving the results in editor, the GeoJSON file is being changed by deleting the 'Z' from the place which indicates the time zone.
After making the field not-editable the issue does not appear (the editor mode does not work for that column).
Steps to reproduce the issue
-
Import a GeoJSON file to QGIS
-
Open a GeoJSON file in the editor/VSCode etc and choose 1 record, close the file. I chose the record with the time for 05:48:56
-
Open its Attribute Table and turn on Editing mode
-
select the same record in a data/time column ("central_utc") in Attribute Table.
-
click in somewhere else (the time zone of previously selected record has changed to my system timezone)
-
save edits and open GeoJSON file once again. The chosen record has no 'Z' in it, which indicates that no timezone is set.
Versions
| QGIS version | 3.34.1-Prizren | QGIS code branch | Release 3.34 |
|---|---|---|---|
| Qt version | 5.15.8 | ||
| Python version | 3.12.0 | ||
| Compiled against GDAL/OGR | 3.8.0 | Running against GDAL/OGR | 3.8.1 |
| PROJ version | 9.3.0 | ||
| EPSG Registry database version | v10.094 (2023-08-08) | ||
| GEOS version | 3.12.1-CAPI-1.18.1 | ||
| SQLite version | 3.44.2 | ||
| PDAL version | 2.6.1 | ||
| PostgreSQL client version | unknown | ||
| SpatiaLite version | 5.1.0 | ||
| QWT version | 6.2.0 | ||
| QScintilla2 version | 2.14.1 | ||
| OS version | Linux Mint 21.2 | ||
| Active Python plugins | |||
| layout_panel-main | 0.3 | ||
| mask | 1.10.2 | ||
| quick_map_services | 0.19.34 | ||
| pdaltools | 0.1.6 | ||
| DissolveWithStats | 0.6 | ||
| mapswipetool_plugin | 1.2 | ||
| LAStools | 2.0.1 | ||
| MapsPrinter | 0.9 | ||
| qgis_resource_sharing | 1.0.0 | ||
| grassprovider | 2.12.99 | ||
| MetaSearch | 0.3.6 | ||
| processing | 2.12.99 | ||
| db_manager | 0.1.20 | ||
| otbprovider | 2.12.99 |
Supported QGIS version
- [X] I'm running a supported QGIS version according to the roadmap.
New profile
- [x] I tried with a new QGIS profile
Additional context
related issues: https://github.com/qgis/QGIS/issues/48393
Example file: Issue.zip
I am afraid this is not an easy fix, see the discussion here: https://www.mail-archive.com/[email protected]/msg51484.html
https://github.com/qgis/QGIS/issues/48393 is much the same problem. I do not know why it was closed, because the problem still exists.
I think the problem is that QGIS ignores UTC time and presents the data as local time. The gpkg file in https://github.com/qgis/QGIS/issues/48393 : https://github.com/qgis/QGIS/files/8592150/test_data.zip has a timestamp filed of "2022-04-13T12:05:23.000Z" with the "Z" flag, as does the geojson file you show, but QGIS drops the Z and naively uses/presents it as local time. And when you edit the field, passing it through QGIS's internals, it writes the bare internal data back to the file.
Some folks say you should record, store, and handle the data in UTC and only use timezones for presentation in the UI. That would be the safest way to design your process, and thinking that way, the errors here are two:
- presenting UTC time data as if it were local in the UI
- storing data in the files without the Z/UTC time (The numbers aren't actually changed to a different timezone, QGIS is sloppy to not write the Zs.
If you decide to work with UTC data for everything besides presenting in the UI (the only sane choice) solving (2) is relatively straightforward: always write the "Z"s.
