You're building a scheduling app—a Calendly competitor, a booking system, a calendar feature inside a larger product. A user creates a recurring weekly meeting on Mondays at 2 PM. Simple enough.

Then Monday falls on Memorial Day. Or Christmas. Or a bank holiday in the UK but not the US, and your meeting has participants in both countries.

What should happen?

Option 1: The meeting stays on the holiday. Now you've scheduled a meeting when half your participants are off work, and they'll blame your app when they miss it or have to decline.

Option 2: Skip the holiday. But RRULE—the standard for recurring calendar events—doesn't natively support "skip holidays." You can't just set a recurrence rule that says "every Monday except holidays." You have to generate the occurrences and then filter or reschedule the ones that fall on holidays. Which holidays? For which countries?

Option 3: Move the meeting to the next business day. Now you need business day calculation that accounts for both weekends and holidays. And if your meeting has participants in multiple countries, you need a date that's a business day in all of them.

This is what scheduling app developers actually deal with. Not "put an event on a calendar." A maze of holiday calendars, timezone conversions, and business day logic that users expect to Just Work.

If you read forums for scheduling apps—Calendly, Cal.com, Acuity, Doodle—the same requests come up constantly:

"Allow recurring events to skip holidays and pick the next working day."

"Show holidays on the calendar so I don't accidentally book meetings on them."

"Warning if an appointment is scheduled on a holiday."

"Support for different holidays in different countries for international teams."

These aren't edge cases. They're basic expectations for any scheduling tool used by people who work across countries or need to respect local holidays. Calendly has holiday blocking—it's a selling point. Many competitors don't, and users notice.

The feature requests reveal what's actually needed:

• Know which days are holidays in which countries

• Display those holidays on calendars

• Warn when scheduling conflicts with holidays

• Handle recurring events that should skip holidays

• Calculate "next available business day" across multiple timezones

Holidays are one problem. Timezones are another.

A meeting at "3 PM Eastern" is straightforward until:

• One participant is in a timezone that observes DST and another isn't

• It's the week when Europe changes clocks but the US hasn't yet (or vice versa)

• Someone's in India (+5:30) or Nepal (+5:45) with non-standard offsets

• A participant is in Israel or UAE where the workweek is different

A common developer complaint: "I recently came across an issue involving timezones. There were some unit tests making assertions about dates that used to work at my office in France but weren't working in Morocco for new members on our team."

The standard advice is "store everything in UTC," and that's correct, but it doesn't solve the display problem. When you show users available time slots, you need to show them in each participant's local time, correctly adjusted for whatever DST rules apply on that specific date.

And if you're finding times that work across multiple timezones, you need to know:

• What's 9 AM to 5 PM in each participant's timezone?

• Which of those hours overlap?

• Are any of the overlapping hours on a weekend or holiday for any participant?

This is hard. Most scheduling apps either ignore it (and frustrate international users) or implement partial solutions that break in edge cases.

Let's be specific about the data requirements:

Not just US federal holidays. Your users have teams in Germany, India, Brazil, Singapore. Each country has its own holiday calendar. Some have regional variations (Bavaria vs. Berlin in Germany). Religious holidays like Eid and Diwali fall on different dates each year.

You need holiday data for every country your users operate in, updated annually and when governments announce changes.

Users should see holidays on their calendar view. When they try to schedule something on a holiday, they should get a warning: "December 26th is a public holiday in the United Kingdom. Schedule anyway?"

This requires knowing not just that a date is a holiday, but which holiday it is and where it's observed.

Given a date, what's the next business day? This requires knowing:

• Which days are weekends in the relevant country (not always Saturday-Sunday)

• Which days are holidays

• Whether to consider one country or multiple (for international meetings)

For recurring events that should skip holidays, you need to generate occurrences, check each against the holiday calendar, and reschedule the conflicts to the next business day.

Every timezone in the IANA database, with current UTC offset and DST status. You need to know that "America/New_York" is currently UTC-4 (during DST) or UTC-5 (during standard time), and when the transitions happen.

For scheduling across timezones, you need to convert times accurately and find overlapping availability windows.

RRULE is the iCalendar standard for recurring events. "Every Monday" is FREQ=WEEKLY;BYDAY=MO. It's widely supported, interoperable, and doesn't know anything about holidays.

If you want "every Monday except holidays," you have two options:

EXDATE: Explicitly exclude specific dates. You'd generate the Mondays, check which ones are holidays, and add those to the EXDATE list. This works, but the EXDATE list grows over time, and you need to regenerate it when holiday data changes.

Post-processing: Generate occurrences from the RRULE, then filter or modify them based on your holiday calendar. This is more flexible but means you're maintaining two representations of the event schedule.

Neither is elegant. The standard wasn't designed for holiday awareness. You're working around it.

This is a common enough problem that feature requests for "RRULE with holiday support" appear across every scheduling platform. The solutions are all application-level workarounds built on top of holiday data.

We built World Data API to provide the underlying data that scheduling apps need:

Holiday calendars for 230+ countries. Public holidays, bank holidays, and major observances. Updated annually and when governments announce changes.

Regional granularity. Germany's 16 Länder, Australian states, Canadian provinces, Indian states. Not just "national holidays" but the holidays that apply to specific locations.

Timezone data. All 316 IANA timezones with current UTC offset, DST status, and transition dates. The data you need for accurate timezone conversions.

Business day calculations. Add or subtract business days from a date. Find the next business day. Count business days between dates. The arithmetic that scheduling logic requires.

We're a data API, not a calendar system. There are things outside our scope:

RRULE processing. We don't parse or generate RRULE strings. You'd use a library like rrule.js or python-dateutil for that, then use our data to filter/modify the results.

Custom holiday inputs. You can't add user-specific or company-specific holidays to our API calculations. If your users observe holidays we don't cover, you'll need to merge our data with your own.

Half-day handling. Days like Christmas Eve that are half-days in some contexts are treated as full days (either business days or holidays) in our calculations. No half-day precision.

Availability management. We can tell you which days are holidays. We can't tell you when a specific person is free or busy. That's your calendar integration's job.

Calendar sync. We don't integrate with Google Calendar, Outlook, or Apple Calendar. We provide reference data; calendar integration is your responsibility.

Scheduling UI. We provide data. Building the date picker, time slot selector, and booking flow is your app's job.

We're the data layer underneath scheduling logic. We know which days are holidays and how to calculate business days. What you do with that information—block slots, show warnings, reschedule recurring events—is your application logic.

Here's a specific scenario that scheduling apps handle poorly:

A company has employees in New York, London, and Tokyo. They want a weekly all-hands meeting. What time works?

New York business hours: 9 AM - 5 PM Eastern London business hours: 9 AM - 5 PM GMT/BST Tokyo business hours: 9 AM - 5 PM JST

The overlap is limited. During US summer (EDT), there's a window in the New York morning that's London afternoon and Tokyo evening. During US winter (EST), the window shifts.

Now add holidays. The meeting is on Monday. But this Monday is a US holiday. Next Monday is a UK bank holiday. The Monday after that is a Japanese holiday. The recurring meeting needs to handle all three calendars.

Most scheduling apps either:

• Ignore international complexity (works for domestic-only use)

• Let users manually manage conflicts (works, but tedious)

• Implement partial solutions that break in edge cases

A complete solution requires holiday data for all relevant countries, timezone conversion that handles DST correctly, and business day calculation across multiple jurisdictions. It's not rocket science, but it's a lot of data to maintain.

You're building a scheduling application—a Calendly competitor, a booking system, an appointment scheduler, a calendar feature inside a larger product.

You want to show holidays on calendars and warn users about scheduling conflicts. You want recurring events to handle holidays gracefully. You want timezone conversion that actually works for international teams.

You don't want to maintain holiday calendars for 230 countries, track when governments announce new holidays, or debug timezone edge cases involving Nepal's +5:45 offset.

You want the data layer handled so you can focus on the scheduling logic and user experience.

The API is REST-based, returns JSON, and authenticates via the X-API-Key header.

Holiday data and timezone data are available on the free tier—60 requests per day, enough for development and light usage. Business day calculations are a premium endpoint requiring a paid tier.

Paid tiers: Starter at $9/month (15,000 requests), Pro at $49/month (100,000 requests), Growth at $149/month (500,000 requests). Annual billing saves about 25%.

Sign up at worlddataapi.com/dashboard to get an API key. Documentation is at worlddataapi.com/docs. We have guides for scheduling-related use cases:

• Building a Meeting Scheduler Across Timezones

• Building a Holiday Calendar in React

• Timezone-Aware Applications

• International Holiday Support