OGR do not write date/times in ISO format

[ygversil]

Not sure if this is a bug or an expected behavior. Feel free to close if not relevant. Seems to be related to #2183, but IMHO, OGR should write datetime fields in ISO format.

Expected behavior and actual behavior

I have isolated this simple CSV file with a datetime column. When I convert it into other formats, I except the column to looks like ISO-8601 format, at least with dashes (-) (and not slashes (/)).

More precisely, I expect values in this column to look like 2019-05-21T10:47:00 or 2019-05-21 10:47:00 or even the unchanged 2019-05-21 10:47:00+02. But actual results look like this: 2019/05/21 10:47:00+02.

Steps to reproduce the problem

Since I cannot attach .csv, here is a tiny excerpt that you can copy and paste into a layer.csv file.

fid,observation_timestamp
1,2019-05-21 10:47:00+02
12,2019-05-22 13:10:00+02
29,2019-05-28 10:40:00+02

• run ogr2ogr -f "GPKG" ogr_out.gpkg -oo HEADERS=YES -oo AUTODETECT_TYPE=YES layer.csv
• OGR recognizes types correctly. But look into the layer table inside the ogr_out.gpkg file : all date/times look like 2019/05/21 10:47:00+02,
• same thing if you convert to CSV : ogr2ogr -f "CSV" ogr_out.csv -lco STRING_QUOTING=IF_NEEDED -oo HEADERS=YES -oo AUTODETECT_TYPE=YES layer.csv

Operating system

Arch Linux

GDAL version and provenance

GDAL 3.0.4, released 2020/01/28 from the official Arch Linux repositories (community).

[rouault]

OGR historical formatting is not ISO format, but YYYY/MM/DD HH:MM:SS+TZ, so what you observe is "by design"

[ygversil]

OK, thanks. Was expecting this. Think I can cope with it in client code with date parsing libraries such as dateutil for Python. As soon as OGR can read its own output and 9917ae7 is published ;)

Thanks for the great work!