This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author jondo
Recipients berker.peksag, ghaering, jondo, matrixise, p-ganssle
Date 2018-11-05.21:47:21
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1541454441.71.0.788709270274.issue35145@psf.upfronthosting.co.za>
In-reply-to
Content
Paul, the sniffing would be only active for people who explicitly add a connect() argument like detect_types=DETECT_DATETIME, which can have the appropriate warning in the docs. You can also extend the sniffing to all values, not just the first non-missing one. (I'd gladly pay the computational price.) How many cases are there where a column is full of `YYYY-MM-DD HH:MM:SS.SSS` data, DETECT_DATETIME is switched on, and the user _doesn't_ want this column to be interpreted as datetime?

(I'm of course not suggesting to try detecting REAL as Julian day, or INTEGER as Unix Time.)

Forget about my test file, by the way:
I have now found out that I can extract the DATETIME type information from my test file SQLiteStudio-3449.sqlite in the following two ways:
```
In [3]: pd.read_sql_query('pragma table_info("t")', con)
Out[3]: 
   cid name      type  notnull dflt_value  pk
0    0    x      TEXT        0       None   0
1    1    y  DATETIME        0       None   0

In [4]: pd.read_sql_query('SELECT SQL FROM sqlite_master WHERE name = "t"', con)
Out[4]: 
                                   sql
0  CREATE TABLE t (x TEXT, y DATETIME)
```
For my real use case however, those two statements yield empty results :-(
History
Date User Action Args
2018-11-05 21:47:21jondosetrecipients: + jondo, ghaering, berker.peksag, matrixise, p-ganssle
2018-11-05 21:47:21jondosetmessageid: <1541454441.71.0.788709270274.issue35145@psf.upfronthosting.co.za>
2018-11-05 21:47:21jondolinkissue35145 messages
2018-11-05 21:47:21jondocreate