Migrate school holidays to OpenHolidays API#544
Migrate school holidays to OpenHolidays API#544KristjanESPERANTO merged 1 commit intoopening-hours:developfrom
Conversation
KristjanESPERANTO
force-pushed
the
sh
branch
2 times, most recently
from
12b5fb2 to
e7f787e
Compare
|
Is it easy possible to keep historic data in the existing files? |
|
Looks very promising! This PR relates to #300. I also have a slight preference to keep historical data. But I don’t see a real use case either. If the default release we do only contains say a few years into the past than that should be fine. A build option could be added that creates a release with all holiday definitions. But that is optional. I guess the proper way to keep the historic data would be to upstream it to https://github.com/openpotato/openholidaysapi.data but I would also say it is not worth the effort. Another idea: Instead of using the API, https://github.com/openpotato/openholidaysapi.data could be added as git submodule. It is very small and having it as submodule would make the process of generating more auditable/reproducible. But I only peeked at the data files and your script. |
|
I asked over there and they would be happy to have this historic data... |
I'll take a look at it.
Thanks for checking it out! I'll see if I can somehow convert it into their format. |
|
About the historic data we made some progress (openpotato/openholidaysapi.data#152). There is still an open PR (openpotato/openholidaysapi.data#154) on this; but once it has been done, we can close this topic and don't lose our historic data with the migration 😃 I have changed this PR to draft and will leave the status until I have dealt with the topic “using the data from the repository instead of the API”. |
|
The migration of the historic data is done 😃 Before proceed with this PR here, I would like to resolve that issue: openpotato/openholidaysapi.data#155 |
|
I converted the PR from a API approach to a submodule approach as suggested (and updated the PR text accordingly). PR is ready for review 🙂 |
Migrate school holiday data from manually maintained YAML files to automated generation from OpenHolidays Git submodule, expanding coverage from 8 to 33 countries. Implementation: - Add openholidaysapi.data as Git submodule - Create fetch-school-holidays.mjs to parse CSV files from submodule - Generate subdivision entries using full names from subdivisions.csv - Merge generated SH data with existing YAML PH data - Add export validation for index.js Migrated countries (8): at, be, de, fr, hr, hu, lu, ro New countries (25): ad, al, bg, by, ch, ci, cz, dk, ee, es, ie, it, li, lt, lv, mc, md, mt, mx, nl, pl, pt, rs, si, sk, sm, za Tests updated from 2014-2015 to 2024-2025 timeframe. Update data: node scripts/fetch-school-holidays.mjs
ypid
left a comment
ypid
left a comment
There was a problem hiding this comment.
I skimmed through it. Nice work! Looks good.
|
@ypid Thanks! I think now after merging this is a good time for a release 🙂 If that goes well, I might look at migrating PH next. |
3 participants
Migrates school holiday data from manually maintained YAML to automated OpenHolidays data via Git submodule, expanding coverage to 33 countries 🎈
Approach Evolution
Initially implemented using the OpenHolidays REST API, but switched to Git submodule approach for reliability:
Why the change?
Changes
openholidaysapi.dataas Git submoduleat,be,de,fr,hr,hu,lu,roscripts/fetch-school-holidays.mjs) that parses CSV files from submoduleCONTRIBUTING.mdBenefits
node scripts/fetch-school-holidays.mjsgit submodule updateto get latest dataBreaking Change
No. Our historical school holiday data was transferred to OpenHolidays. Existing functionality remains unchanged.