Slightly different weekend treatment in TARGET calendar && removed 31.12. from TARGET calendar

[NiklasRodi]

What is this PR for?

Slightly different weekend treatment in TARGET calendar:

• Assume you have a NEWYORK calendar that also adds WEEKDAY automatically as base calendar. Now you want to built union of TARGET and NEWYORK calendars by building a NEWYORK calendar with TARGET as base. Then you have NEWYORK with base WEEKDAY with base TARGET with base WEEKDAY. That is a bit ugly
• This is just a cosmetic change. Weekends will still be non-bussinesdays in the TARGET calendar

Removed 31.12. from TARGET calendar

What type of PR is it?

Improvement/Feature

[cfries]

However: I assume that the && operator ensures that the test for weekend is performed only once, regardless of how many base calendars are excluding the weekends.

[NiklasRodi]

Deleted. Just saw your comment

[cfries]

Yes. And make it final.

Am 08.06.2017 um 12:02 schrieb NiklasRodi notifications@github.com:

@NiklasRodi commented on this pull request.

In src/main/java6/net/finmath/time/businessdaycalendar/BusinessdayCalendarExcludingTARGETHolidays.java https://github.com/finmath/finmath-lib/pull/30#discussion_r120847276:

@@ -45,7 +44,9 @@ public boolean isBusinessday(LocalDate date) { LocalDate datePlus2 = date.plusDays(2); LocalDate dateBefore = date.minusDays(1);

• return (baseCalendar == null || baseCalendar.isBusinessday(date))
• BusinessdayCalendarInterface weekdayCalendar = new BusinessdayCalendarExcludingWeekends(); How about I add the member "private BusinessdayCalendarInterface weekdayCalendar = new BusinessdayCalendarExcludingWeekends()" to the TARGET calendar?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/finmath/finmath-lib/pull/30#discussion_r120847276, or mute the thread https://github.com/notifications/unsubscribe-auth/ADo8H9E-JOhTuTUqVv_phg6eeFH3VSTjks5sB8bHgaJpZM4Nzy4B.

[cfries]

The point with the debugging (that is the impact on toString()) is a good one!

LGTM.