>
> This is also fast: SELECT * FROM data WHERE tstr BETWEEN tbegstr AND
> tendstr; And it works just as well if dates are in the ISO8601 format.


Aha, yes, thanks, this is certainly a better SELECT than converting string
data to numeric Julian Days. And the string can have as much resolution as
needed and represent times in leap seconds (with "60" in the seconds field).

I still see potential advantages with the numeric (day segmented) timestamp
regarding disk storage, e.g. my data are continuously over 1-2 years with
sub-second sampling. Using time strings I would need all 23 bytes allowed
in the Sqlite date and time functions.
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to