Fix TimeRange.duration() to use non-fudged start end end times
GENERAL
TESTING
GENERAL
TESTING
Description
In the implementation of MyTimeRange in BasicTimeService.java, duration() uses this computation to figure duration:
(lastTime().getTime() - firstTime().getTime());
Seems reasonable enough, except when you look at lastTime() and firstTime() - they add and subtract a fudge factor to help in overlap checking.
public Time firstTime() { return firstTime(1); } // firstTime
I can see lots of places where code might assume that lastTime() and firstTime() are pure getters - but that fudge code is from 2008 and not worth changing and retesting all of calendar.
So the fix is to compute duration using the non-fudged first and last times:
(lastTime(0).getTime() - firstTime(0).getTime());
The problem is that some code grabs duration and then uses it to adjust things for recurring events (i.e. MWFRecurrenceRule.java line 180 in calendar). This assumption that duration was real was what caused the problem in -SAK-23076-. The fix from -SAK-23076- was incorrect and while it fixed the "off by a minute" problem in it broke things as described in SAK-30793.
So the solution is to truly fix the duration() code and revert the change in -SAK-23076-.
In the implementation of MyTimeRange in BasicTimeService.java, duration() uses this computation to figure duration:
(lastTime().getTime() - firstTime().getTime());
Seems reasonable enough, except when you look at lastTime() and firstTime() - they add and subtract a fudge factor to help in overlap checking.
public Time firstTime() { return firstTime(1); } // firstTime
I can see lots of places where code might assume that lastTime() and firstTime() are pure getters - but that fudge code is from 2008 and not worth changing and retesting all of calendar.
So the fix is to compute duration using the non-fudged first and last times:
(lastTime(0).getTime() - firstTime(0).getTime());
The problem is that some code grabs duration and then uses it to adjust things for recurring events (i.e. MWFRecurrenceRule.java line 180 in calendar). This assumption that duration was real was what caused the problem in -SAK-23076-. The fix from -SAK-23076- was incorrect and while it fixed the "off by a minute" problem in it broke things as described in SAK-30793.
So the solution is to truly fix the duration() code and revert the change in -SAK-23076-.