3 ms·
This is very exciting! The pace of sqlite development is suprisingly fast for a project that mature. The only real type that I miss from SQLite is a native dat
by Sytten 3y ago
This is very exciting! The pace of sqlite development is suprisingly fast for a project that mature.
The only real type that I miss from SQLite is a native datetime. Currently each library uses a different parsing strategy and it's a mess. I fixed the diesel (rust) implementation recently and boy was that not fun.
- Aeolun 3y agoDoesn’t it use ISO format everywhere? I thought that was pretty well standardized at this point.
- giraffe_lady 3y agoIt's pretty standardized in the sense that like, that's what most sqlite users choose to do for dates. But it doesn't have a datetime type, and has native functions for generating both iso strings and unix epoch numbers. It really is kind of up to and on the user to decide and stick to one approach. So you definitely do see differences between programming languages based on how their sqlite libraries chose to do it. Or between libraries in the same language, if there are multiple good choices.
- em500 3y agoSQLite has no date/time types, only strings and numbers, and functions that can interpret certain strings or numbers as date/times. That design choice actually made a lot of sense in the past, because unlike most other databases SQLite didn't have rigid typed columns. Now you could roll your own rigid column types using CHECK constraints, but then you would just use the date/time functions to enforce date/times column values, so there was no need for separate date/time datatypes. But recently they've implementedn STRICT tables with rigid column types, so maybe they'll add date/time datatypes at some point as well.
- euroderf 3y agoAs I understand the docs... You can use "DATE" and "DATETIME", and they default to NUMERIC affinity, and therefore a string that can't be parsed as a number will be parsed as TEXT, which defaults to ISO-8601.