> > 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