thunderbird-website
thunderbird-website copied to clipboard
use free software to generate public calendars
Hi!
I'm not sure this is the right place for this request, but I have found out that the Thunderbird website ships world calendars, thanks to Nextcloud suggesting those calendars in its user interface:
https://www.thunderbird.net/en-US/calendar/holidays/
While trying to figure out where that data was generated, I stumbled upon this project which, in its README file, says:
Calendar generation can be manually built by appending the option
--buildcalendar. This queries our current calendar provider (Calendarific) and generates a.icsfile per each locale specified in settings.py. For testing, you can limit this to just US by using the option--enus. This option requires setting theCALENDARIFIC_API_KEY=environment variable. If you're using a paid plan you can also setCALENDARIFIC_IS_FREE_TIER=falseto remove the sleep time between calls.
Unfortunately, Calendarific doesn't seem to be providing or based on free or even open data. In fact, their terms of service seem to indicate Thunderbird might actually be in breach of the agreement, as it infringes on point 4.2.e:
4.2. Permitted Use. [...] The following is a non-exhaustive list of practices that would not be considered "Legitimate Use": [...] (e) Redistribute or resell the Data or the Services (wholly or in part).
I have not reported this to the Calendarific people, of course.
I have found two Python libraries that provide similar data:
I encourage you to consider switching to one of those for generating the ICS files! It would reduce legal exposure to the Thunderbird project, at least.
I also think the data source should be credited on the website. If you switch to those free libraries, it could also encourage collaboration in the wider "time and date" community and possibly convergence over such tools and data sources, reducing overall maintenance burden.
Thank you for your consideration.
@anarcat thanks for suggesting holidays as a potential alternative. I'm Ark, a maintainer of the holidays package.
Here are some key points about the project:
Pros:
- MIT License – Ensures long-term openness and flexibility for Thunderbird.
- Efficiency – Optimized for fast lookups and minimal resource usage.
- Ongoing Maintenance – Actively developed with regular updates.
- Stable Release Schedule – New stable releases are published on the 1st and 3rd Monday of every month.
- Growing Adoption – Around 9M downloads per month.
- Expanding Coverage – Actively working on adding more countries -- WIP https://github.com/vacanza/holidays/issues/1141.
- High Code Quality – Maintains 100% test coverage to ensure reliability.
Cons:
- Fewer Supported Entities (Currently ~160 vs. 230+ in Calendarific) – However, the list is expanding, with a focus on ISO 3166 compliance.
- Lower Outside Contributor Involvement – Most contributions come from core maintainers (@arkid15r, @KJhellico, and @PPSyrius), but efforts are being made to grow the community. We plan to participate in Google Summer of Code 2025 and are currently involved in Winter of Code, where I am mentoring four students to accelerate development.
We would be happy to collaborate to ensure holidays meets Thunderbird's needs. Let us know if there are specific requirements we should prioritize.
for what it's worth, i wrote a simple wrapper to generate .ics files for all zones supported by calendra here:
https://github.com/jaraco/calendra/issues/36
Quick update: The holidays library now includes built-in support for generating ICS (iCalendar) files starting from version 0.70.
The official documentation is available here: https://holidays.readthedocs.io/en/latest/examples/#generate-icalendar-content-and-export-to-ics
Thanks all, and doubly so for the update! I've noted this issue down to investigate when we find some free time.
Generally replacing the ics provider with something else is on the backlog anyways:
- #650
Just from glancing the recent calendar issues, there are:
- #803
- #357
- #791
- #804 etc.
So perhaps just starting with US, if anyone willing to generate a @vacanza/holidays output and compare it to the current ics, if that looks better both in terms of validation and not being noisy regarding state/regional holidays? (Would it make sense to start generating subdivisions for larger nations so folks could only subscribe to their state/province?)
I see every country necessary listed there: https://github.com/vacanza/holidays/#available-countries with the only exception being Guyana (https://github.com/vacanza/holidays/issues/1196) due to GY vs. GF clash.
(EDIT: I only checked the calendars currently listed at https://thunderbird.net/calendar/holidays not digging deeper in the older caldata, there's probably more like Basque, Jewish, Iran, Queensland, Quebec, Flanders, Frisian, separate EN+CY vs. NIR vs. SCO and similar subdivisions that were provided in the past… but figured these would be outdated today anyways, and whatever new solution is picked it could be extended from the current set to whatever the data provides, as long as there's no regional controversy etc.)
Unfortunately, Calendarific doesn't seem to be providing or based on free or even open data. In fact, their terms of service seem to indicate Thunderbird might actually be in breach of the agreement, as it infringes on point 4.2.e:
We don't redistribute their data in any systematic way. One of their suggested uses is "integrate holiday data into your commercial application" which would be pretty hard to do without displaying or providing holiday data so I am not concernd about the license and I do not think we are in breach at all.
I have found two Python libraries that provide similar data:
* [Holidays](https://github.com/vacanza/holidays/): [no ICS output](https://github.com/vacanza/holidays/issues/2179), but [pending PR](https://github.com/vacanza/holidays/pull/2261) * [Calendra](https://github.com/jaraco/calendra): [built-in ICS output](https://workalendar.github.io/workalendar/ical.html)
We do want to switch away from calendarific, I think. At the time we started using it appeared to be the best option, but it doesn't seem like it still is. The hard part about calendar libraries is keeping them up to date and correct for every locale, converting data formats and output is pretty easy.
What we need is for someone to investigate the different libraries(and there are many issues filed in this repo about specific holiday problems..) and figure out which one does that best. If any are using an external source for their actual underlying data, then they're only as good as whatever that source is.
Normally I would close this in favor of #650 but since this has more information in it I'm doing the opposite.
@eyJhb @janbrasna @MelissaAutumn @Sancus I'm vacanza/holidays maintainer (we're migrating to Open World Holidays Framework name).
What we need is for someone to investigate the different libraries(and there are many issues filed in this repo about specific holiday problems..) and figure out which one does that best. If any are using an external source for their actual underlying data, then they're only as good as whatever that source is.
We're totally open to external pull requests or just feature requests properly describing issues that need to be addressed to make your users happier. We completely own the "source" of the holidays data -- it's actually a Python code. So we don't rely on any external libraries/packages (we use official sources to confirm/verify holiday dates/names/observance/etc).
We are very active open-source community that works hard on their project. This year we're going to add at least 25 more countries thanks to GSoC participation under PSF umbrella with estimated 15-20M monthly downloads by end of 2025.
Let me know if you have any other concerns regarding vacanza/holidays framework fitting your needs -- I'll be happy to help with resolving them.
Cons:
* **Fewer Supported Entities (Currently ~160 vs. 230+ in Calendarific)** – However, the list is expanding, with a focus on ISO 3166 compliance. * **Lower Outside Contributor Involvement** – Most contributions come from core maintainers ([@arkid15r](https://github.com/arkid15r), [@KJhellico](https://github.com/KJhellico), and [@PPsyrius](https://github.com/PPsyrius)), but efforts are being made to grow the community. We plan to participate in **Google Summer of Code 2025** and are currently involved in **Winter of Code**, where I am mentoring four students to accelerate development.
A quick update on what's changed since Feb. -- we've been working on fixing our weaker spots. With GSoC-related contributions (again, thanks PSF for onboarding us) and our sponsorship incentive (June, July) we've been working towards full ISO 3166-1 entities coverage. We added 40+ entities since Feb and expect to complete full ISO 3166-1 support by end of year (pessimistic ETA). My personal expectation is Oct-Nov.
The bottom line:
- It's currently 200+ entities supported by Open World Holidays Framework with realistic goal to cover entire ISO 3166-1 list by end of 2025
- The sponsorship program attracted more external contributors so it's no longer a concern for the core team.
After nearly 4 months of work the Open World Holidays Framework has reached full compliance with the ISO 3166-1 standard.
Starting with release v0.83 (October 20, 2025) the framework will include support for all 249 ISO 3166-1 entities.
The GitHub repository commenthol/date-holidays that was recommended in https://github.com/thunderbird/thunderbird-website/issues/650 is a popular JavaScript module that provides dates of holidays for many countries, states, and regions worldwide, with consideration for timezones. It is well-maintained, with ongoing contributions and many supported locales. The data in the project mostly derives from Wikipedia articles and is licensed under CC BY-SA 3.0.
The repository is recommended for holiday data and has been used to generate the public holiday calendar files in the Android app FossifyOrg/Calendar. To give an example country, all Swedish public holidays (except one known issue) are included in the FossifyOrg/Calendar project's Swedish public.ics. It also generates The Swedish other.ics. By contrast, Thunderbird currently misses 5 of 13 public holidays in SwedishHolidays.ics:
- https://github.com/thunderbird/thunderbird-website/issues/941
The pypi package from commenthol was one of the considered ones IIRC. At least I'm using their outputs to tell people to look at, and provide feedback on the data;)
Another one I might have missed earlier is https://github.com/workalendar/workalendar — they also seem to have added direct ical exports: https://workalendar.github.io/workalendar/ical.html
(However they state: "This library is ready for production, although we may warn eventual users: some calendars may not be up-to-date, and this library doesn't cover all the existing countries on earth (yet)." — Whereas we've seen the activity on the vacanza tracker to be a sign the data provided there get a lot of "Vox populi" street cred…)
What might be a little limiting regarding the actual deployment currently is e.g. "Workalendar will require you to use Python 3.7+" — but as I've noted earlier, we could probably separate the ical generation from the thunderbird-website code, and make a GitHub action that would just publish a gh-pages—like deployment with the cal data, and proxy that from some thunderbird subdomain, so it doesn't even have to live here and be generated from within this repo.
I can confirm with v0.83 of @vacanza/holidays there are no longer any missing locales in the calendar build #829 for the set here — the last two GY_en and LB_ar have been added recently.
I'm now bouncing around the content with some reporters in regions, who had issues with the existing data.