-
-
Notifications
You must be signed in to change notification settings - Fork 2.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ogr2ogr: for e.g. for GPKG files, naive datetimes in src are represented as being UTC in dst file #11212
Comments
Naive datetimes and times with localized timezones are not supported in the GeoPackage standard so if you aim at interoperability, don't use them even GDAL allows to do it. |
Slightly related improvement in #11213 , but won't fix that particular use case |
@jratike80 it is a bit broader than GeoPackage, also for other file formats the treatment of datetimes is sometimes not ideal, typically when arrow is used under the hood. For some of the issues there are technical complications why this is the case as discussed in geopandas/pyogrio#487 . The file formats I tested were GeoJSON, GeoJSONSEQ, FlatGeoBuffer and Geopackage. I added some extra relevant cases to the reproduction script above:
|
Doesn't the GeoPackage creation option DATETIME_FORMAT=[WITH_TZ/UTC] https://gdal.org/en/latest/drivers/vector/gpkg.html#dataset-creation-options change anything? |
,no, it won't. The issue with Arrow is that in Arrow DateTime columns must declare their timezone (or the absence of one), at the column level. Whereas GeoPackage DATETIME_FORMAT=WITH_TZ (the default) allows to create rows in a same column with different timezones. So when reading back with Arrow, as we don't know if there's a single timezone used or a mix, we normalize to UTC |
What is the bug?
Datetime columns are not always treated correctly/consistently:
This issue is already being discussed in the context of the integration in pyogrio via the C API here. Just posting it here as well for completeness sake and to document that the same behaviour occurs in ogr2ogr as well when arrow is used internally.
Steps to reproduce the issue
UPDATE: added FlatgeoBuffer to the script + with versus without using arrow
Output:
Versions and provenance
Additional context
No response
The text was updated successfully, but these errors were encountered: