Provide holiday data and basic functions as separate (npm) module

[ypid]

As suggested by AMDmi3 a long time ago.

There are quite some holiday modules already on npm. I will have to check them out and see which ones can be reused.

This is also intended to allow holiday definitions of arbitrary complexity. See Russian holidays and US holidays. And to allow other projects to reuse the handy list of public/school holidays which this library has collected by now.

• Review other npm packages and add refs to readme or check if a package already exists which uses a similar format than opening_hours.js and discuss if projects can/should merge.
• Create package.json below holidays.
• Compile legacy JS file with rollup below holidays.
• Write readme how the holidays can be used standalone (ES6, and legacy JavaScript) (importing and accessing should be enough. Users will need to figure out how to evaluated them on their one).
• Publish to npm. @ypid would like to do this to stay in control of the holidays.

[ypid]

Seems that all other holiday modules are not useful to start with because there API is very limited and the data they bundle is only for one country. Did I miss one? I will probably just package the definition as own NPM in the future. All functions which operate on the definition are too strongly tight with opening_hours.js.

[ypid]

Checkout https://stackoverflow.com/questions/14203708/is-there-a-comprehensive-api-or-json-xml-list-with-public-bank-holidays-worldwid

[d1g]

I found less popular answer https://www.mozilla.org/en-US/projects/calendar/holidays/ Quality of data is questionable but it like this approach: import from iCal-like format (this is what every calendar program +/- supports). It will be dead-easy to create custom calendars and use them in OH.js.

Support for PH dates and custom PH dates or external services can be activated/deactivated via configs.

[ypid]

Looks like a reasonable data source. The reason I have not used ical for this previously is historical. I actually got the definitions for German and Austria from a superseded oh implementation by user Netzwolf. The advantage was, that instead of relying on precalculated icals (I don’t think that variables dates like easter can be expressed in ical) we can actually calculate the PHs ourself and don’t need to rely on anything else. I guess this approach will take time to reach full coverage but I think it is the best technical solution. Using icals would only be a substitution and data set to check our data against. See also anschuetz/linuxmuster#2 where I precalculated such PR/SH definitions until the year 2042 using the lib 😉 for a script used in German schools.

Also note that I use ical already in the project where holidays are not deterministic/can not be calculated. One example are German SH. See the https://github.com/opening-hours/opening_hours.js/blob/master/convert_ical_to_json script.

[ypid]

The module will be written in Haxe to prepare the planned rewrite of the core functionally in Haxe. Ports will be published to all supported targets.

[ypid]

Ref: #198

[shouze]

@ypid do you think it's still realistic to keep this issue in this milestone? Looks like a lot of work no? I'm ok to help if you can split in bullet points tasks 😉

[ypid]

You are welcome to help. I added the steps I see to solve this issue. I already thought about this and the holiday definitions can stay part of this git repo as they are integration tested here also. So this is about providing them to others on npm.

[shouze]

ok thx!

[ypid]

#300 should be done first. Maybe we can instead merge with another project that already provides holiday data.