>> We don't use seconds. We use milliseconds since the Unix epoch.
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)
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
Seconds are not fine-grained enough to differentiate events, so we should store
the timestamps as floating-point numbers.
Mailing list: https://launchpad.net/~zeitgeist
Post to : firstname.lastname@example.org
Unsubscribe : https://launchpad.net/~zeitgeist
More help : https://help.launchpad.net/ListHelp