Recognize more date formats when importing data

Context

Please explain here below what you were doing when the issue happened

I was importing a CSV file via the Carto web interface.

Steps to Reproduce

Please break down here below all the needed steps to reproduce the issue

1. Import a new dataset from file

Current Result

Please describe here below the current result you got

Dates, for example 09/17/1993 00:00:00, were imported as strings.

Expected result

Please describe here below what should be the expected behaviour

It would be very helpful if the column were created as a TIMESTAMP.

Browser and version

What internet browser (Chrome, Firefox, etc) and version was you using and version

n/a

.carto file

Don’t forget to rename .carto file to .zip file to be able to upload to github

n/a

Additional info

Please add any information of interest here below

[rafatower]

The right repo is this one: https://trac.osgeo.org/gdal

@rouault I tried to create a ticket there but I no longer have TICKET_CREATE privileges. Here’s the content of the ticket I wanted to create:

Support more date and datetime formats for AUTODETECT_TYPE option

The `AUTODETECT_TYPE` option of the CSV driver does a great job figuring out the types of the columns of an input CSV file but can be improved by adding more formats to it.

At present and if I'm not mistaken, the algorithm for type detection only supports the ISO 8601 Notation.

Here are the types supported by PostgreSQL:
https://www.postgresql.org/docs/current/static/datatype-datetime.html#DATATYPE-DATETIME-DATE-TABLE

The algorithm could be tweaked to support those formats that do not have ambiguity with other types (integer or float), so that, for instance, the following CSV would recognise the column mydate as of type datetime:
{{{
id,mydate,value
1,09/17/1993 13:20:51,42
2,09/17/1994 13:27:40,43
}}}

I think the code implementing it is around these lines:
https://trac.osgeo.org/gdal/browser/trunk/gdal/ogr/ogrsf_frmts/csv/ogrcsvlayer.cpp?rev=37371#L1160

What do you think? we can keep the discussion about feasibility and estimates off this public repo

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.