Timeseries starting from 0 are unsupported

[Karan Lyons]

> ts.create test 100
> ts.add test 0 5
> ts.range test 0 100
(empty list or set)
> ts.add test 1 5
> ts.range test 0 100
1) 1) (integer) 1
   2) "5"

This is likely due to a comparison check between timestamp and lastTimestamp. This isn’t actually a personal issue for me, but it’s irksome and I’d like to submit a pull for it if there’s not a reasonable reason for this behavior.

Note that in addition it’s perhaps wise not to consider the timestamp as any specific unit to begin with as I don’t think such an assumption is made anywhere in code (beyond just variable names) and truly our only constraint is that the value for timestamp be monotonic and >= 0 (though currently with this bug we require >0), which additionally should allow us to use uint32_t for timestamp_t/api_timestamp_t, unless there’s a place doing subtraction with them that I haven’t come across.

[Karan Lyons]

So the assumption that timeseries won’t ever contain t=0 is a bit pervasive, to the point where I even relied on it in my last pull. I think I’ve got that solved mostly, though.

As for changing timestamp_t/api_timestamp_t to uint32_t, apart from having to include stdint.h this wasn’t much of a change, and this frees up a bunch of headroom for the timestamps, and I don’t think this module ever supported negative timestamps anyway. I may be forgetting some portability issue with this type declaration, though.

Presuming that these two fixes are made, I’d say the code and documentation should be changed to be unit agnostic with regard to timestamps. This would also clear up some confusion seen in other pull requests asking to support milliseconds and whatnot. Technically milliseconds are already supported.