search

ology / Date-Holidays-USA

Provides United States of America holidays
https://metacpan.org/dist/Date-Holidays-USA
Artistic License 2.0
0 stars 0 forks source link

Logic on what "holidays" to include? #1

Open mrdvt92 opened 3 months ago

mrdvt92 commented 3 months ago

What is the goal of your package that is not being met by one of these other packages?

There are now four US-based holiday adaptors in Perl. You manage one, I manage two, and one is defunct.

There is also this non Date::Holidays package.

How could we make a single architecture to meet the needs of all use cases? Could your package that adds holidays be a wrapper or super class of one of them? A goal of the Date::Holidays architecture is that the US adaptor could pass a state or region code. Maybe we could add region-like support for holidays like Groundhog's Day. States also all have their own holidays they even might name them differently than the Federal Holidays.

ology commented 3 months ago

Thank you for this report.

I found that none of the others had all of the holidays. The goal is to provide all the holidays recognized (both federal and cultural). Maybe a wrapper including all of them, with the "Nth day of month" algorithm... I will re-investigate.

ology commented 3 months ago

Ok I'm finally getting back to this issue. Apparently I did not diff things correctly, and figure out a "better" solution.

Diff'ing NYSE with your module, I see that NYSE has Good Friday, but not Veteran's or Columbus/Indigenous-peoples days. And my module vs yours, has 9 additional holidays.

perl -MData::Dumper::Compact=ddc -MDate::Holidays::NYSE=holidays -E'$h = holidays(shift); say ddc $h' 2024

perl -MData::Dumper::Compact=ddc -MDate::Holidays::US=holidays -E'$h = holidays(shift); say ddc $h' 2024

perl -MData::Dumper::Compact=ddc -MDate::Holidays::USA -E'$dh = Date::Holidays::USA->new; $h = $dh->holidays(shift); say ddc $h' 2024

So in addition to being a "wrapper" it would need to add holidays to the list that your module provides. I'll contemplate how best to do this. We could also deprecate mine, in favor of yours including the 9 extra holidays that mine has.

(And I would rather not go down the possible rabbit-hole of region support... But it can certainly be added in The Future™.)

Thoughts? :)

-Gene

ology commented 3 months ago

I will craft a pull request for perl-Date-Holidays-US, to include these extra, "culturally recognized" holidays. Then I can deprecate mine when it's merged and uploaded to CPAN.

(And this will involve using the simple "nth day of month" algorithm, instead of the multitude of elsif conditions.)

ology commented 3 months ago

No. On second thought, and after rereading your description, "Date::Holidays Adapter for US Federal holidays back to 1880 with updates from 2022" - Federal

Since you have federal covered, I will turn mine into one that only lists "culturally recognized" holidays, and rename it.

mrdvt92 commented 3 months ago

using the simple "nth day of month" algorithm

Using DateTime is a heavy package for the more simple calculations. You might be able to use POSIX for many cases to gain performance.

Date::Easter

I'm using Date::Calc::Easter_Sunday for Easter references (Mardi Gras, Ash Wednesday, etc.) in NYSE so if you may want to use that package for consistency or if the package you pick is more widely accepted and I could move to that package. I normally pick the package based on if my OS supports it first. Further, it would be great to add the Equinoxes and Solstices but it might be difficult to calculate what particular "day" they fall on in the USA since we have time zones from USVI to Guam. A good start on the "holidays" list is the free printable calendars and the node holidays package.

sub us_holidays {

Per the spec I think this should be usa_holidays and is_usa_holiday.

sub is_holiday {

Your architecture requires calculating all holidays even if only one day is requested (and it does not appear to be cached). My package does the opposite. It's quite easy to wrap with the same logic as my package since my sub holidays() is portable where you can just drop it in if you build your logic in is_holliday().

mrdvt92 commented 3 months ago

I'm using Date::Calc::Easter_Sunday for Easter references (Mardi Gras, Ash Wednesday, etc.) in NYSE so if you may want to use that package for consistency or if the package you pick is more widely accepted and I could move to that package

I looked at the code for both of these Easter packages and they are using totally different calculations. Both, are supported in my OS. Date::Easter looks to be a lighter package.

ology commented 3 months ago

Thank you. I will revisit when I'm not swamped at the $day_job.

ology commented 3 months ago

Ok. Returned from speaking at TPRC2024. Time to get back to it... I guess you're not interested in adding the extra holidays in my feeble module, to yours. So, I am thinking that I'll refactor and rename this module to be Date::Holidays::US::Extras or something like that. I will investigate what you have said about calculating Easter, not using DateTime, and optimizing things.

ology commented 1 week ago

I am just going to rename Date::Holidays::USA to Date::Holidays::USExtended.

Apologies for naming my extended set such a confusing name! Ugh

mrdvt92 commented 1 week ago

Date::Holidays::USExtended.

I think it might make more sense to make a Cultural package and then another overlay package that brings in Federal, Market and cultural in one fat package. Let me know if you want help with the architecture.