Skip to content
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

Merged
merged 1 commit into from
Sep 6, 2021
Merged

Replace start date in schedule #2353

merged 1 commit into from
Sep 6, 2021

Conversation

jodastephen
Copy link
Member

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.

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
Copy link
Contributor

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

Copy link
Member Author

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.

Copy link
Contributor

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

Copy link
Member Author

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.

@jodastephen jodastephen merged commit 9064e43 into main Sep 6, 2021
@delete-merged-branch delete-merged-branch bot deleted the topic/replace branch September 6, 2021 08:32
@jodastephen jodastephen added this to the v2.11 milestone Jan 5, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants