Recent changes to bugs

common classes are duplicated in the common and joda jars

2012-01-24T12:45:36Z

The maven-enforcer-plugin's excellent duplicate class finder extension tells me that these classes are packaged in *both* the datecalc-common and the datecalc-joda jar files:

Found in:
net.objectlab.kit:datecalc-joda:jar:1.2.0:compile
net.objectlab.kit:datecalc-common:jar:1.2.0:compile
Duplicate classes:
net/objectlab/kit/datecalc/common/AbstractIMMDateCalculator.class
net/objectlab/kit/datecalc/common/HolidayCalendar.class
net/objectlab/kit/datecalc/common/Utils.class
net/objectlab/kit/datecalc/common/ExcelDateUtil.class
net/objectlab/kit/datecalc/common/DefaultHolidayCalendar$DateComp.class
net/objectlab/kit/datecalc/common/KitCalculatorsFactory.class
net/objectlab/kit/datecalc/common/DefaultHolidayCalendar$1.class
net/objectlab/kit/datecalc/common/StandardTenor.class
net/objectlab/kit/datecalc/common/AbstractDateCalculator$1.class
net/objectlab/kit/datecalc/common/AbstractKitCalculatorsFactory.class
net/objectlab/kit/datecalc/common/HolidayHandler.class
net/objectlab/kit/datecalc/common/PeriodCountBasis.class
net/objectlab/kit/datecalc/common/Tenor.class
net/objectlab/kit/datecalc/common/DefaultHolidayCalendar$CalendarComp.class
net/objectlab/kit/datecalc/common/TenorCode.class
net/objectlab/kit/datecalc/common/DefaultHolidayCalendar.class
net/objectlab/kit/datecalc/common/IMMDateCalculator.class
net/objectlab/kit/datecalc/common/PeriodCountCalculator.class
net/objectlab/kit/datecalc/common/HolidayHandlerType.class
net/objectlab/kit/datecalc/common/DateCalculator.class
net/objectlab/kit/datecalc/common/ImmutableHolidayCalendar.class
net/objectlab/kit/datecalc/common/WorkingWeek.class
net/objectlab/kit/datecalc/common/AbstractDateCalculator.class
net/objectlab/kit/datecalc/common/IMMPeriod.class

This appears to me to be unintentional, bearing in mind that the datecalc-joda pom declares a dependency on the datecalc-common artifact. Is the datecalc-joda packaging including the common class files in error?

My current workaround is just to exclude the datecalc-common transitive dependency:
<exclusion>
<groupId>net.objectlab.kit</groupId>
<artifactId>datecalc-common</artifactId>
</exclusion>

This works because everything required is already present in datecalc-joda.

WorkingWeek(byte xx) must be public

2011-12-07T13:14:29Z

i tried to set the workingdays from monday to sunday. (7days) ==> i tried to set on the DateCalculator the attribute setWorkingWeek but i can not create a WorkingWeek as i wished to because the constructor is protected.
please provide also some most used cominations like you did with DEFAULT_WORKING_DAYS
eg for 7 days or sun-fr.

i like you framework :-)

cheers :-)

Spot date calculation is invalid

2010-10-11T07:59:21Z

Spot date is now calculated as "Today+2 business days". This can be found in AbstractDateCalculator.java :
if(tenorCode != TenorCode.OVERNIGHT && tenorCode != TenorCode.TOM_NEXT && spotLag != 0)
moveByBusinessDays(spotLag);

But the correct algorythm should be "Today+2 days except weekend". And if the calculated date will be holiday then it should be moved to the next business day.
For example if today is Friday and there is a holiday on Monday, then current implementation says that spot date for today is Wednesday. But it should be Tuesday actually

DefaultHolidayCalendar is broken for Date / Calendar JDK

2010-03-04T19:01:48Z

There is a problem if you use the DefaultHolidayCalendar<E> with Date or Calendar holidays, i.e. JDK implementation.

The Date / Calendar objects are not "equal" on the same day if they have different time zones, and as a result isHoliday() method doesn't work correctly.

Negative moves do not work for FORWARD_UNLESS_MOVING_BACK…

2008-12-04T15:09:07Z

… except for LocalDateForwardUnlessNegativeHandler.

Indeed their getType() implementation returns FORWARD instead of FORWARD_UNLESS_MOVING_BACK, so AbstractDateCalculator.moveByBusinessDays(int) throws an IllegalArgumentException…

MODIFIED_PRECEEDING HolidayHandlerType

2008-03-31T03:45:31Z

I'm thinking that the spelling of MODIFIED_PRECEEDING should be fixed. (Should be "_PRECEDING".)

http://objectlabkit.sourceforge.net/multiproject/datecalc-common/apidocs/net/objectlab/kit/datecalc/common/HolidayHandlerType.html#MODIFIED_PRECEEDING

(I don't know why I didn't notice this when I recorded bug 1601542, but in the end it was Eclipse that pointed out the misspelling.)

MODIFIED_FOLLLOWING

2006-11-23T06:01:45Z

I'm thinking that the spelling of MODIFIED_FOLLLOWING should be fixed.

http://objectlabkit.sourceforge.net/multiproject/datecalc-common/apidocs/net/objectlab/kit/datecalc/common/HolidayHandlerType.html#MODIFIED_FOLLLOWING