Support adjusted start date for StandardRollConventions (e.g. IMM).#1580
Merged
brianweller89 merged 6 commits intomasterfrom Oct 24, 2017
Merged
Support adjusted start date for StandardRollConventions (e.g. IMM).#1580brianweller89 merged 6 commits intomasterfrom
brianweller89 merged 6 commits intomasterfrom
Conversation
…s return a day in the month based on a defined rule, such as IMM.
jodastephen
approved these changes
Oct 23, 2017
| if (adjDate.equals(baseDate)) { | ||
| return rollImpliedDate; | ||
|
|
||
| if (rollConvention != null) { |
Contributor
There was a problem hiding this comment.
Worth checking this in the calling code I think
| {date(2018, 3, 22), date(2020, 03, 18), P6M, STUB_NONE, IMM, BDA_JPY_MF, null, null, BDA_NONE, | ||
| ImmutableList.of(date(2018, 3, 21), date(2018, 9, 19), date(2019, 3, 20), date(2019, 9, 18), date(2020, 3, 18)), | ||
| ImmutableList.of(date(2018, 3, 22), date(2018, 9, 19), date(2019, 3, 20), date(2019, 9, 18), date(2020, 3, 18)), IMM}, | ||
| {date(2018, 3, 20), date(2019, 03, 20), P6M, STUB_NONE, IMM, BDA_JPY_P, null, null, BDA_NONE, |
Contributor
There was a problem hiding this comment.
a test without STUB_NONE?
|
|
||
| //If the adjusted roll date equals the original base date then that the base date is in fact an adjusted date | ||
| //and hence return the unadjusted date for building the schedule. | ||
| if (adjustedRollDate.equals(baseDate)) { |
Contributor
There was a problem hiding this comment.
It would be helpful to use the same local variable names for similar concepts, such as rollInpliedDate and adjDate.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Previous code only supported conversion of adjusted to unadjusted dates for numeric or EOD convention.
This code attempts to calculate an unadjusted date from an adjusted date as follows
This relies on the assumption that the adjusted roll date will never be in a different month to the original unadjusted date. This is relatively safe for the existing StandardRollConventions as the rules for choosing a day in the month will never result in a date close to EOM. The latest possible calculated roll day for the existing roll convention is the 21st of the month (for IMM, if the first of the month is a Thursday). This is sufficiently far from EOM that no reasonable adjustment will result in the adjusted date being in the next month. Similarly the earliest possible date is 7th of the month (for IMMNZD).
The existing implementation for numeric roll convention suffers from a similar problem e.g. if unadjusted roll day of 28th is adjusted using FOLLOWING then the resulting adjusted date could be in the following month. This would result in the date not being identified as adjusted.
This logic will not work for weekly roll conventions in most cases. adjust() method for weekly roll conventions calculates the next weekday which matches the convention. If the passed date has been adjusted forward then it will not be identified as a valid adjusted date; the calculated unadjusted date will be the next occurrence of that weekday, rather than the previous e.g.
See comments in code for (even) more detail.
An alternative approach could be to associate the logic for converting to unadjusted with each roll convention by adding a new method to the RollConvention interface; this would however be an intrusive and breaking change.
This is still a bit of a hack, so open to suggestions for alternatives!