-
Notifications
You must be signed in to change notification settings - Fork 284
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Replace start date in schedule #2353
Conversation
Create an algorithm to replace the start date in a schedule This handles most cases sensibly Where necessary, schedule generation is used to convert a final stub convention to a last regular end date
builder.stubConvention(StubConvention.SMART_INITIAL); | ||
} else if (stubConvention.isFinal()) { | ||
if (lastRegularEndDate != null) { | ||
// last regular is set, so the final stub convention can be safely changed |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't follow why the stub convention can be safely changed in this case. The roll day of the last regular end date should be in sync with the roll day of the trade start date.
For example, if I have existing trade with
Start Date: 2021-06-01
End Date: 2026-07-01
Frequency: 6M
Last Regular End Date: 2026-06-01
This gives me a trade with 6M periods and a 1M stub at the end.
If I then come along and change the start date to 21-06-15 using this method I am left with what looks like an inconsistent trade definition
Start Date: 2021-06-15
End Date: 2026-07-01
Frequency: 6M
Last Regular End Date: 2026-06-01
Stub Convention: Smart Initial
So the presence of a Last Regular End date that is different to the trade end date implies a back stub.
But we are then explicitly saying this trade has an initial stub
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Smart initial has been changed to cope with this. The smart stub conventions now respect any first or last regular date, and apply themselves to the remaining period.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok so SmartInitial
can actually result in a trade with both a front and back stub?
Not the most intuitive but we're in to real edge case territory here anyway, so I agree the behaviour here is sensible enough
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, SmartInitial
and SmartFinal
now have reasonable behavour for a use case that previously threw an exception.
Create an algorithm to replace the start date in a schedule. This handles most cases sensibly.
Where necessary, schedule generation is used to convert a final stub convention to a last regular end date.