[prev in list] [next in list] [prev in thread] [next in thread] 

List:       qgis-developer
Subject:    Re: [QGIS-Developer] QGIS Date, Time and Time Zones
From:       Even Rouault <even.rouault () spatialys ! com>
Date:       2021-04-30 15:13:18
Message-ID: 0ebc5733-b957-cf0e-b732-453fb7c753e6 () spatialys ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


| Also I wonder if it would be possible to work with the GPKG developers 
to provide better timezone support there as well.

This is more about finding how to convince the GeoPackage spec 
maintainers that it is worth adding it than a technical one. I guess 
they wouldn't want to break compatibility with the core specification, 
so a clean way forward would be to deal with that as an extension, since 
GeoPackage has a mechanism to indicate that a given file uses extensions.

The gpkg_extensions table (https://www.geopackage.org/spec/#_extensions) 
could for example have one record to declare each (layer, field) that 
uses an extended date-time format

|table_name = |||{name_of_table_using_an_extented_datetime_column}
||

||column_name = {name_of_column_using_extended_datetime}||

||extension_name = ogr_extented_datetime (if the OGC SWG would accept to 
officialize it as a registered extension, that would become 
gpkg_extended_datetime)
||

||definition = ||||||https://gdal.org/geopackage_extended_datetime.html 
(or URL to updated GeoPackage spec if officialized)
||||

||||scope = read-write||||

What would be to decide is if the extension consists in relaxing the 
constraints of the existing DATETIME data type (to accept any time zone, 
or lack of time zone), or adding a new DATETIME_EXTENDED data type.


> Do you know what vector formats support timezones properly?

For general purpose formats: FlatGeobuf, GML, GeoJSON (well there's no 
datetime data type in JSON, so this is by guessing that a string looks 
like a ISO8601 formatted datetime...), CSV (same remark as GeoJSON)


-- 
http://www.spatialys.com
My software is free, but my time generally not.


[Attachment #5 (text/html)]

<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>| Also I wonder if it would be possible to work with the GPKG
      developers to provide better timezone support there as well.</p>
    <p>This is more about finding how to convince the GeoPackage spec
      maintainers that it is worth adding it than a technical one. I
      guess they wouldn't want to break compatibility with the core
      specification, so a clean way forward would be to deal with that
      as an extension, since GeoPackage has a mechanism to indicate that
      a given file uses extensions.</p>
    <p>The gpkg_extensions table
      (<a class="moz-txt-link-freetext" \
href="https://www.geopackage.org/spec/#_extensions">https://www.geopackage.org/spec/#_extensions</a>) \
could for example  have one record to declare each (layer, field) that uses an
      extended date-time format<br>
    </p>
    <p><code>table_name = \
</code><code><code>{name_of_table_using_an_extented_datetime_column}  <br>
        </code></code></p>
    <p><code><code>column_name =
          {name_of_column_using_extended_datetime}</code></code></p>
    <p><code><code>extension_name = ogr_extented_datetime (if the OGC
          SWG would accept to officialize it as a registered extension,
          that would become gpkg_extended_datetime)<br>
        </code></code></p>
    <p><code><code>definition = </code></code><code><code><code><code><a \
class="moz-txt-link-freetext" \
href="https://gdal.org/geopackage_extended_datetime.html">https://gdal.org/geopackage_extended_datetime.html</a>
  (or URL to updated GeoPackage spec if officialized)<br>
            </code></code></code></code></p>
    <p><code><code><code><code>scope = read-write</code></code></code></code></p>
    <p>What would be to decide is if the extension consists in relaxing
      the constraints of the existing DATETIME data type (to accept any
      time zone, or lack of time zone), or adding a new
      DATETIME_EXTENDED data type.<br>
    </p>
    <p><br>
    </p>
    <blockquote type="cite"
cite="mid:CABPxTToOyWw2bkf5iJT+0wmPNo+8gLJn-Y1Py17XvP5hDU5D6Q@mail.gmail.com">
      <div dir="ltr">
        <div>Do you know what vector formats support timezones properly?</div>
      </div>
    </blockquote>
    <p>For general purpose formats: FlatGeobuf, GML, GeoJSON (well
      there's no datetime data type in JSON, so this is by guessing that
      a string looks like a ISO8601 formatted datetime...), CSV (same
      remark as GeoJSON)<br>
    </p>
    <br>
    <blockquote type="cite"
cite="mid:CABPxTToOyWw2bkf5iJT+0wmPNo+8gLJn-Y1Py17XvP5hDU5D6Q@mail.gmail.com"></blockquote>
  <pre class="moz-signature" cols="72">-- 
<a class="moz-txt-link-freetext" \
href="http://www.spatialys.com">http://www.spatialys.com</a> My software is free, but \
my time generally not.</pre>  </body>
</html>



_______________________________________________
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer


[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic