** Changed in: zeitgeist
Status: Fix Committed => Fix Released
--
TimeRange.always() is inconsistent
https://bugs.launchpad.net/bugs/614295
You received this bug notification because you are a member of Zeitgeist
Framework Team, which is subscribed to Zeitgeist Framework.
Status in Zeitge
https://code.edge.launchpad.net/~zeitgeist/zeitgeist/timerange_and_event_value_fix/+merge/32574
** Changed in: zeitgeist
Status: Triaged => Fix Committed
--
TimeRange.always() is inconsistent
https://bugs.launchpad.net/bugs/614295
You received this bug notification because you are a membe
We need to settle on this so I can fix it quickly... I hate pesky little
bugs
** Changed in: zeitgeist
Status: New => Triaged
** Changed in: zeitgeist
Importance: Undecided => Low
** Changed in: zeitgeist
Importance: Low => Medium
** Changed in: zeitgeist
Assignee: (unassigned
As far as I can see its not really a breakage of the API. It is under the hood
and the interface is still the same There are no events prior 1970 stored
on the computer. Thus it makes most sense to have something consistent and
valid. How do you want to calculate the timestamp for 1901 -.-
(
2010/8/6 Mikkel Kamstrup Erlandsen :
> Regarding change of timestamp signature: What's the technical argument
> for breaking API (and breaking it in a big way)?
I don't really think we should break it now (just saying that it'd
make more sense, but in practice I don't think it'll make a
difference
I am pretty much indifferent on TimeRange.always() is. The .is_always()
function is just used in the fts extension to do a slight optimization
in case the time range is irrelevant.
Regarding change of timestamp signature: What's the technical argument
for breaking API (and breaking it in a big way
6 matches
Mail list logo
