John Crenshaw wrote: >> *if* you know that the number *is* a date. >> > > If the column has a type of timestamp, it should be safe to always > assume that it IS a date. sqlite> CREATE TABLE t1 (StartTime TIMESTAMP, Duration REAL); sqlite> CREATE TABLE t2 AS SELECT StartTime, StartTime + Duration / 86400.0 AS StopTime FROM t1; sqlite> SELECT sql FROM sqlite_master WHERE name = 't2'; CREATE TABLE t2(StartTime TIMESTAMP,StopTime)
What column type? > Don't put non-dates in it, and there isn't a > problem. I can't imagine a case where you would not know whether the > value is a date. Am I missing something here? > Consider the case of an application using an SQLite database to store its settings (like the Windows registry, but portable). The dynamic type system is great for this. CREATE TABLE Settings (Name TEXT PRIMARY KEY, Value BLOB); Name Value ----------------- --------------- LogPath 'E:\log\FooApp' MaxAttachmentSize 2500000 LastUpdate 2455130.1125 Now, in the SQLite equivalent of regedit, how is it supposed to know that LastUpdate is timestamp 2009-10-25 14:42:00 but MaxAttachmentSize is NOT the date 2132-08-31 12:00:00? Without knowledge of the application that created this table, it can't. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users