The rtree docs say that as well as 2D geometry, it could be used to
index ranges of time - this is what I'm doing, but I've found a
problem and workaround:
It seems that the indexed values are stored as a small floating-point
value, and thus large numbers (for example, the current timestamp as
seconds since 1970) will be approximated. The date right now, for
example (1335201433) is rounded to the nearest 128 seconds, where I
need accuracy to thousandths of a second. Once I'd realised what was
happening, the workaround was to store the date of the first sample in
a different table, and then index the offset from that date. Having to
subtract and re-add the offset every time I'm looking up indexed data
is annoying, but nothing fatal.
If a larger float could be stored without breaking speed and
compatibility, that would be good; if not, could the docs at least
point out that while rtree indexes are generally suitable for time
ranges, they aren't suitable for high-precision-seconds-since-epoch
time ranges? (Listing all the things a bit of software isn't suitable
for would be silly, but I think in this case it deserves mention as
it's the most simple and intuitive approach that doesn't quite work)
-- Shish
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
