> > On reading, the SQLite driver will currently only accept data with stored > > as text (speaking here about the content of each cell, not the declared > > column type!) and will try to parse them as ISO-8601. If the values are > > stored as floating point or integer values, it will report null. It > > might be good to implement the rule at 1.2 Date and Time Datatype of > > https://www.sqlite.org/datatype3.html to convert from Julian days or Unix > > time.
I've added support to recognize floating point values in a Date/DateTime column and convert from Julian fractional days to the expanded representation used by GDAL. Only on reading. If you create/update records, they will be output as ISO-8601 text. > > I agree and I think that on the Spatialite side it might be good to make > the spatialite tools to declare the columns which are known to contain > dates/times as DATE/DATETIME even those types do not really mean anything > for SQLite and huge amounts of existing and future Spatialite databases > hold dates and times in columns which are declared as TEXT, INTEGER, > DOUBLE, or without a type at all. > > All in all, handling dates is the typeless SQLite in a reliable and > interoperable way seems to be a bit complicated. I will think about writing > a line or two into http://www.gdal.org/drv_sqlite.html about how GDAL plays > with them once I understand it myself. > > -Jukka- > _______________________________________________ > gdal-dev mailing list > [email protected] > http://lists.osgeo.org/mailman/listinfo/gdal-dev -- Spatialys - Geospatial professional services http://www.spatialys.com _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
