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

Reply via email to