exchange_calendars
exchange_calendars copied to clipboard
Why does `orthodox_easter` have a default end date?
The orthodox_easter
method was used for some time to get Orthodox Easter holidays for ASEX. It has since been pulled out of the ASEX-specific code as it's now also used for XBSE.
The method has two arguments, start_date
and end_date
, with default values of 1980
and 2022
, respectively.
This issue is to ask if it actually makes sense to configure an end date which coincides with the current or next year (as of the time the code is written/updated).
I think it actually makes sense to have this open-ended, or possibly restricted by some global end date that automatically slides forward as time progresses. This would be to reflect that an exchange that observes holidays relative to Orthodox Easter is probably more likely to continue that in the future rather than changing observances (status quo assumption).
Ideally, any restriction would also be done per-exchange as exchanges may start or stop observing the affected holidays independently of each other.
Setting the default end date to the current year or the one after, at the time of a code update, also carries a risk for anyone using the exchange_calendars
package, but missing a few future updates. The problem then becomes that the package effectively will no longer spit out the correct holidays in future years as it will stop respecting the Orthodox Easter holidays when the end date has passed, despite the rules still being valid. So one would rely on updating the package in time, hoping that the end date has now been adjusted there. To minimize the risk, I think it would be best to put any end date far into the future.
So, in essence, should we remove the current configured default end date on the method orthodox_easter
, and if so, what's the correct end date (ideally far into the future) to configure?
@jenskeiner, I suspect the TODO here is probably the first route of enquiry. Would it be possible to define the orthodox easter adhocs as regular holidays?
If they can't be then I agree that setting the default as either a rolling future year or a year far into the future would be preferable to the current hard-coded 2022. In this case:
-
bound_end
and_bound_end_error_msg
methods should be defined for the affected calendars (to prevent calendars being created beyond the date up to which orthodox_easter is evaluated - indeed, as it is they should be defined with bound end as end 2022). - a note should be added to the
orthodox_easter
doc advising contributors to implement the above methods to any calendar that currently observes holidays related toorthodox_easter
.
#314 moved the default end date to 2030.