zeitgeist team mailing list archive

[Mikkel Kamstrup Erlandsen <mikkel.kamstrup@xxxxxxxxx>]

>> We don't use seconds. We use milliseconds since the Unix epoch.
>Do we? 
I believe you meant to say "o rly?!" :-) Anyway, in the places where I've coded I've used int(time.time()*1000) and time() returns seconds since the Epoch...

While walking the dog I had some further thoughts on why reals/floats
are such a bad idea...:

 * We can not use == for comparison. This means that we can not use a
simple CONSTRAINT in the SQL to guard against duped events. Furthermore
an Event "equals" function becomes meaningless becuase we can not do ==
on the timestamps. We can only use a "roughly equals" by checking that
the timestamps lie within a small delta.

 * We lock down our internal data representation because we can not use
"bit fiddling" with floats. As an example from the real world I had to
pack a timestamp into a 64 bit int (in the lower 40 bits) and use the
remaining 24 bits to hold a unique id. This gave a *huge* performance
increase in my particular situation - AND allowed me to keep backwards
compat with a DB schema. Tricks like these are not possible if we hard
code ourselves to a float

-- 
Use timestamps with milliseconds granularity (was: use REAL)
https://bugs.launchpad.net/bugs/483603
You received this bug notification because you are a member of
Zeitgeist-Engine, which is the registrant for Zeitgeist Engine.

Status in Zeitgeist Engine: New

Bug description:
Seconds are not fine-grained enough to differentiate events, so we should store the timestamps as floating-point numbers.