Fix: float timestamps should be absolute

[feelingsonice]

Not sure if this is intentional. I found where float timestamps were being shifted relative to the first data point (see test file). Perhaps there's something I'm not understanding about the design here but I thought this might be a bug. Please close if intended @inakleinbottle

[inakleinbottle]

This was to allow for datetime timestamps to be provided for ticks, and it is supposed to be an internal reparameterisation that shouldn't have affect the external parameterisation. This hasn't worked correctly. To convert from datetime to floating point parameters one must first convert to timedeltas, which requires a "point of reference" from which deltas are calculated.

[feelingsonice]

That makes sense, especially for datetime-like timestamps if the user wants an internal “seconds since some reference datetime” representation. My concern is specifically about plain float timestamps. In that case, the float already is the external parameter value, so rebasing the first tick to 0.0 changes the user-visible parameterization rather than just the internal representation.

For example, if the data has ticks at t=3.0 and t=5.0, the current behavior stores them internally at 0.0 and 2.0. Then a query on [0, 2) incorrectly includes the first event, even though externally the stream should be empty on that interval.

[feelingsonice]

@inakleinbottle I see the tests are failing. I think a more comprehensive fix might be an explicit split like:

• Numeric timestamps: store them as-is as param_t.
• Datetime/date/time timestamps: convert them to internal deltas from a stored reference datetime.
• External datetime queries: map them back through the same stored reference using schema parameterization.
• Mixed timestamp kinds in one stream: reject clearly.

I'm happy to draft something like that if you think it's worth it :)