>> 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. _______________________________________________ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp