Similar to Perl, SQLite doesn't do strong typing. They seem rather militant about it, in fact.
This behavior is a feature, not a bug. A database is suppose [sic] to store and retrieve data and it should not matter to the database what format that data is in. The strong typing system found in most other SQL engines and codified in the SQL language spec is a misfeature - it is an example of the implementation showing through into the interface.Having to parse out dates and calculate date differences manually would be a serious PITA.
Or does SQLite have a way to do this? I haven't looked.
Re:Dates
jdavidb on 2002-12-19T20:25:52
I don't know about SQLite, but Perl gives me date arithmetic with Matt Sergeant's Time::Piece. I've had decent luck doing date parsing when needed with HTTP::Date.
I would just as soon DBI queries give me date values as a Time::Piece.
Re:Dates
jdavidb on 2002-12-19T20:27:34
For that matter, barring the troubles of parsing the user input, if SQLite doesn't do dates and I need them, I would use Time::Piece objects on the Perl side and convert them to epochtime for storage on the DB side. Conversion to and from epochtime is simple with Time::Piece, arithmetic and comparisons are simple, and output formatting is simple.
Hmmm, date parsing would seem to be the only thing Time::Piece is lacking...
Re:Dates
tex on 2002-12-19T21:11:27
I use Time::ParseDate with Time::Piece when strptime isn't going to work well.Time::ParseDate adds a bit of overhead though, so I try to use strptime where I can rely on dates coming back in a specific format (like date values from a database).
