[gdal-dev] Bad Date Handling
Ari Jolma
ari.jolma at gmail.com
Tue Apr 5 22:08:00 PDT 2016
05.04.2016, 22:09, Even Rouault kirjoitti:
> Le mardi 05 avril 2016 20:56:07, Paul Ramsey a écrit :
>> Hey all,
>>
>> We've had a client working with dodgy data who would like an option to
>> avoid incompatible date mangling when reading bad data. Basically, OGR
>> will consume some funky dates from CSV and Excel, like 0000/00/00, but
>> it will NULL out others, like 1971/34/34. The net result is that, when
>> the data are written out to PgSQL, is some null values, and other
>> values that get converted to things PgSQL cannot consume (0000/00/00
>> becomes 2000/00/00 and PgSQL then errors out on that).
>> They'd like to just coerce *all* invalid dates to NULL,
>>
>> I've done a small patch that does that, in the presence of a config
>> flag, any thoughts on if it's acceptable?
> Paul,
>
> Why not rather improving the datetime parser to reject invalid dates like
> 0000/00/00 ? In OGRParseDate() in ogr/ogrutils.cpp. That way that would solve
> the issue not only for Postgres output, but for all other drivers.
Just to note that I suggested some improvements and a config option to
printing and reading dates in a github pull request(*). I did not
suggest checking the date in OGRParseDate() but it could be also done
with strptime(). For Windows strptime() needs to be redone but there are
useful options.
Ari
(*) The pull request is https://github.com/OSGeo/gdal/pull/105/files but
it seems to be cluttered with the map_algebra code I've written into the
same fork.
>
> Even
>
More information about the gdal-dev
mailing list