> On 19 Sep 2018, at 05:23, Konstantin Osipov <kostja@tarantool.org> wrote:
> 
> * Nikita Pettik <korablev@tarantool.org <mailto:korablev@tarantool.org>> [18/09/18 01:20]:
>> From: Georgy Kirichenko <georgy@tarantool.org>
>> 
>> As a main part of introducing strict typing in SQL it is required to
>> prohibit typeless columns in parser's grammar. Originally, SQLite simply
>> assigns typeless columns to BLOB affinity. Moreover, due to historical
>> reasons, all columns were stored with <SCALAR> type in Tarantool core
>> (except for <INTEGER> when it comes to primary key).  Column type should
>> be defined on table creation. Allowed data types are: <TEXT>, <VARCHAR>,
>> <CHAR>, <BLOB>, <INT[EGER]>, <REAL>, <FLOAT>, <NUMERIC>, <DECIMAL>,
>> <DOUBLE> <DATE> and <DATETIME>. However, still any declared data type is
>> converted to one of <BLOB>, <TEXT>, <REAL> or <INTEGER> affinities.
>> While affinity reaches space format, it is (again) converted to
>> Tarantool's field type. To be more precise, table of conversions:
>> 
>> +----------+----------+------------+
>> | SQL TYPE | AFFINITY | FIELD TYPE |
>> +----------+----------+------------+
>> | FLOAT    | REAL     | NUMBER     |
>> | REAL     | REAL     | NUMBER     |
>> | DOUBLE   | REAL     | NUMBER     |
>> | NUMERIC  | REAL     | NUMBER     |
>> | DECIMAL  | REAL     | NUMBER     |
>> | INTEGER  | INTEGER  | INTEGER    |
>> | TEXT     | TEXT     | STRING     |
>> | VARCHAR  | TEXT     | STRING     |
>> | CHAR     | TEXT     | STRING     |
>> | BLOB     | BLOB     | SCALAR     |
>> | DATETIME | REAL     | NUMBER     |
>> | DATE     | REAL     | NUMBER     |
>> | TIME     | REAL     | NUMBER     |
>> +----------+----------+------------+
> 
> How do you manage to store datetime/date/time values as numbers?
> What is your conversion procedure? Are you storing it as unix
> timestamp? Note that SQL date begins (AFAIR) at 1900-01-01.

Now we don’t have any facilities to process or store DATETIME
format in any convenient way. SQLite originally only features
DATETIME() function, which converts string to REAL type
(in the same way you mentioned).
Hence, temporary this ’type’ works simply as REAL/FLOAT without
any implicit conversions to unix timestamp or date/time validations.
Another option is remove DATETIME type at all - until it will be implemented,
in order to avoid confusions.