DST Scheduling Bugs in Calendar Apps

DST scheduling bugs plague calendar apps across platforms in 2026, turning what should be a straightforward appointment into a moving target. When daylight saving time transitions occur, meetings disappear, shift by an hour, or recur at the wrong time—often because the calendar app's underlying timezone database is outdated, its recurrence engine doesn't account for the transition, or it interprets ambiguous and non-existent times differently than the server expects.

Why This Matters (And When It'll Bite You)

Every March and November (in most of the Northern Hemisphere), 1.5 billion people experience a DST transition. Your calendar app has to answer questions it wasn't built to handle well: what time should a 9 AM meeting become when 2 AM never happens? If you schedule a recurring daily standup that lands on a DST boundary, does it stay at 9 AM local time or jump to 10 AM UTC? What if your co-worker in a region with different DST rules can't even see the meeting time correctly?

The standard calendar format, iCalendar (RFC 5545), was designed to be timezone-agnostic, but implementation varies wildly. A meeting stored in UTC behaves differently when synced across Outlook, Google Calendar, and Apple Calendar—especially if one app has fresher IANA timezone rules than another. For developers building integrations or for team leads managing hybrid schedules across continents, these bugs aren't edge cases; they're failures waiting to happen during the twice-yearly transition window.

This article digs into why these bugs exist, shows real examples of how major platforms fail, and gives you practical ways to detect and work around them.

The Root Cause: IANA Tzdata Version Mismatch

The IANA Time Zone Database (tzdata) is the source of truth for how every region's DST rules work. It's maintained by volunteers and updated whenever a country changes its rules—which happens roughly 20–30 times per year globally. Your calendar app relies on a snapshot of that database, usually bundled at release or occasionally updated as a patch.

Here's the gotcha: a calendar app released in January 2026 might ship with tzdata from November 2025. If a country changed its DST rules in February 2026, the app won't know about it until the next update. Meanwhile, meetings scheduled in that region get calculated with stale rules.

IANA time zones and tzdata define regions by their historical and future DST behavior. Each zone (e.g., America/New_York, Europe/London) has a ruleset specifying when transitions occur and what the UTC offset becomes. When you create a meeting at "2:30 PM Eastern," your app converts that to an internal timestamp using the tzdata rule for America/New_York. If the app's tzdata is old, it might calculate a different UTC time than a newer system would, causing a one-hour misalignment across platforms.

The 2026 reality: Most major platforms (Google, Microsoft, Apple) auto-update their backend tzdata within days of an IANA release. Desktop and mobile apps, especially on older devices, may lag 3–6 months. If you're on a calendar app that doesn't auto-update or that bundles tzdata from its build date, you're vulnerable during transitions.

The Non-Existent Hour: What Happens at 2 AM?

When clocks spring forward—say, at 2:00 AM on March 9, 2026 in most US zones—the time jumps instantly to 3:00 AM. The hour from 2:00 to 2:59:59 AM never happens.

Different calendar apps handle non-existent times in wildly different ways:

• Google Calendar (backend) typically rounds forward: a meeting scheduled for 2:30 AM springs forward to 3:30 AM automatically.
• Outlook may lock it to 2:30 AM UTC and show it as 3:30 AM on the clock, but internally it's treated as the UTC equivalent.
• Apple Calendar sometimes preserves the local clock time (2:30 AM becomes 1:30 AM UTC) and may display it as out-of-order relative to neighboring events.

None of these are wrong, but they're inconsistent. When you sync a meeting between platforms, the non-existent time can get reinterpreted by each system, shifting the actual meeting time by up to an hour.

Practical scenario: You schedule a very early morning standup at 2:15 AM Eastern on March 9, 2026 (a spring-forward day). Google Calendar quietly moves it to 3:15 AM. But if a team member on Outlook sees it scheduled at 2:15 AM and accepts, their system might store the UTC equivalent of the original 2:15 AM, creating a one-hour delta. When both join the Zoom link at their respective "meeting times," one person is an hour late.

The Ambiguous Hour: Which 1:30 AM Do You Mean?

Fall back is the inverse problem: at 2:00 AM on November 2, 2026 (in most US zones), clocks fall back to 1:00 AM, so the hour from 1:00 to 1:59:59 AM happens twice. A 1:30 AM alarm could fire during the first 1:30 AM (EDT) or the second 1:30 AM (EST).

Calendar apps must choose. The standards-compliant answer (RFC 5545) is to favor the first occurrence (Wall clock time before the offset change), but some apps default to the second, and others let you explicitly specify which one you mean.

Real consequence: A meeting scheduled for 1:30 AM on November 2, 2026 in one app might be interpreted as first-1:30 AM (UTC−4) in Google Calendar but second-1:30 AM (UTC−5) in Outlook. That's a one-hour discrepancy on an already-confusing time.

Few developers or team leads even realize this is a decision point, let alone know how their app handles it. DST changes 2026 lists the exact dates; check your app's behavior by scheduling a test meeting at 1:15 AM on a fall-back day and comparing UTC times across platforms.

Recurring Meetings and DST: Why Google Calendar Shifts Times

Recurring events are where DST bugs compound. A daily 9 AM standup scheduled to recur forever will, on most platforms, preserve the local clock time (9 AM) across DST transitions. But the underlying rule (RRULE in iCalendar format) can be defined in UTC or in the specified timezone, and apps disagree on what "9 AM" means when the offset changes.

Google Calendar and Outlook both try to keep 9 AM local time, but they recalculate the RRULE differently when stored and synced:

1. A recurring event created in Eastern Time at 9 AM might be stored as DTSTART:09:00:00 with TZID=America/New_York.
2. When synced to another system, if that system's tzdata is newer or older, it might reinterpret the rule for the transition dates.
3. Worse, if the event is exported to iCalendar and re-imported, the recurrence engine may use the imported timestamps as anchors instead of the original local times, drifting by an hour on DST boundaries.

The bug: A daily 9 AM standup created on March 1, 2026 may show as 9 AM until March 9 (spring forward), then shift to 10 AM for subsequent days if the app's recurrence engine treats the transition as a UTC boundary rather than a local-time boundary.

Recurring meeting DST is a particular pain point for schedule international meetings strategies, because each participant's local time shifts differently depending on their timezone's transition date.

Timezone Database Out of Sync: Why Your App Lags Reality

Even on 2026, a significant gap exists between when IANA publishes a tzdata update and when your specific calendar app ships it.

• IANA releases tzdata on their FTP server (typically once a month, with emergency releases when countries change rules unexpectedly).
• Operating systems (Windows, macOS, Linux) usually update within 1–2 weeks.
• Cloud services (Google, Microsoft, Apple) typically deploy within days.
• Bundled apps (desktop Outlook, older Thunderbird) might wait for the next quarterly or annual release, or never update if the app is discontinued.
• Embedded systems and IoT devices often never receive updates.

If your organization uses a mix of platforms—say, some folks on cloud Outlook, others on desktop Outlook from 2024, others on Google Workspace—you have multiple versions of reality in play. A meeting scheduled in cloud Outlook might show at a different local time in desktop Outlook if they're using different tzdata versions for the same region.

Mitigation: Check your app's tzdata version. On Google Workspace, visit your account settings; the version date is usually listed. For Outlook, Settings → Time & Language shows the system tzdata version. If it's older than 60 days from today (August 12, 2026), and a region's DST rules changed in that gap, you're at risk.

Calendar Storage Formats (iCalendar) and DST

The iCalendar format (RFC 5545) is the backbone of calendar interoperability. It defines how to represent times using either UTC (a Z suffix) or a local timezone (a TZID parameter). The problem: different apps interpret TZID differently, and DST transitions can cause them to misalign.

Here's what a recurring meeting looks like in iCalendar:

BEGIN:VEVENT
UID:standup-daily@company.com
DTSTART;TZID=America/New_York:20260309T09:00:00
RRULE:FREQ=DAILY
SUMMARY:Daily Standup
END:VEVENT

When March 9 hits and clocks spring forward, a fully compliant calendar app should:

1. Interpret 9:00 AM on March 9 as 9:00 AM in America/New_York (which, post-transition, is UTC−4, not UTC−5).
2. Calculate the UTC time as 13:00 UTC (9 AM EDT).
3. Keep subsequent daily occurrences at 9 AM local time.

But if the app that imports this event has outdated tzdata, it might calculate 9:00 AM on March 9 using the pre-transition offset (UTC−5), getting 14:00 UTC instead. The meeting is now an hour off.

Worse, some calendar apps don't embed timezone rules in the iCalendar file—they just store the TZID name and assume the importing system has the same tzdata. This is called "floating time" with a timezone ID, and it's a source of subtle bugs.

Actionable step: Export an event from your calendar app and search for TZID and VTIMEZONE in the .ics file. If you see TZID without a corresponding VTIMEZONE block defining the offset rules, your calendar app is relying on implicit timezone data and is vulnerable to DST bugs when synced across systems.

Real Bug: Outlook and Spring-Forward Meetings

Microsoft Outlook (cloud and desktop versions) has had recurring incidents with spring-forward meetings. The issue typically manifests in desktop Outlook (Windows) versions released before mid-2025.

The bug: A recurring meeting set for 9 AM in Eastern Time, when synced across the DST boundary, sometimes appears as 8 AM for post-transition dates if the Outlook client's tzdata is old or if the sync engine doesn't properly refresh the recurrence rule.

How it happens:

1. You create a daily meeting at 9 AM on March 1 (pre-transition).
2. The meeting is stored with a recurrence rule anchored to the original timestamp.
3. On March 9 at 2 AM, the timezone offset changes from UTC−5 to UTC−4.
4. If Outlook's local tzdata is outdated or if the sync doesn't refresh, the recurrence engine calculates subsequent days using the old offset, effectively subtracting an hour.

Workaround: If you notice a recurring meeting shifting time on a DST boundary, delete and recreate the event post-transition. Or, in Outlook's advanced recurrence settings, explicitly set the recurrence rule to "repeat on specific days" rather than "repeat every N days," forcing the app to use wall-clock times instead of duration-based offsets.

Real Bug: Google Calendar Recurring Event Drift

Google Calendar's backend is usually ahead of the curve on tzdata, but the mobile apps (iOS, Android) sometimes lag. A recurring event created in the web app might sync correctly, but when opened on a mobile app with older tzdata, it drifts.

The specific failure: A daily standup created at 9 AM Eastern in Google Calendar (web) on February 2026 syncs to your phone with the correct tzdata. But if your phone's tzdata is from October 2025, and a DST rule change was published between then and March 2026, the mobile app recalculates the event time for March 9 using outdated rules, shifting it by an hour.

Detection: On your mobile phone, open the event on March 9 and check the local time it shows. Compare it to what the web app shows. If they differ by an hour on a DST transition day, your phone's tzdata is stale.

Fix: Update your phone's OS. Google Calendar on Android relies on the system tzdata version; forcing an update on both OS and app usually resolves drift. On iOS, Apple Calendar often has the same issue; check Settings → General → Date & Time to confirm automatic updates are enabled.

Real Bug: Apple Calendar and Half-Hour Zones

Apple Calendar has a known edge case with timezones that have non-standard (non-whole-hour) UTC offsets, like Asia/Kathmandu (UTC+5:45) or Asia/Kolkata (UTC+5:30). When DST is involved in these zones (rare, but it happens), Apple Calendar sometimes rounds the offset to the nearest hour, shifting meetings by 30 minutes.

Why it matters: If you're scheduling meetings across teams in Nepal or parts of India and Australia, and DST-adjacent regions are involved, you may see 30-minute shifts on transition days. This is less common than the full-hour bugs, but it's insidious because it's not an obvious one-hour error.

Workaround: For teams crossing half-hour zones, consider scheduling in UTC or using a fixed timezone (like America/Los_Angeles) and letting each participant convert locally. Alternatively, use async vs sync meeting decision frameworks to reduce the number of real-time meetings across half-hour zones entirely.

How to Test for DST Bugs in Your Code

If you're building a calendar integration, syncing events, or managing meeting automation, here's a checklist to validate DST handling:

1. Verify your tzdata version before and after a DST transition. Use a library like pytz (Python), moment-timezone (JavaScript), or DateTimeZone (.NET) and check the version it reports.

2. Create test events at DST boundaries: Schedule a recurring daily event 3 days before spring forward (e.g., March 6 at 9 AM), set it to recur for 10 days, and inspect each occurrence's UTC time. All should be consistent (same number of minutes from midnight UTC, adjusted for offset changes).

3. Test non-existent and ambiguous times explicitly:

   • Schedule a one-off event at 2:30 AM on a spring-forward day (non-existent).
   • Schedule a one-off event at 1:30 AM on a fall-back day (ambiguous).
   • Check the UTC time in your database and verify it matches your app's calculated value.

4. Sync across platforms: Export an event from one calendar app (Google, Outlook, Apple) and import it into another. Compare the UTC times and local times for events on DST transition days. Discrepancies indicate a bug.

5. Check iCalendar output: Export an event as .ics and parse it. Verify that either the UTC time is correctly set (with a Z suffix) or the TZID and VTIMEZONE definitions are included and match your tzdata version.

6. Automate for your transition dates: DST changes 2026 lists the dates. Build a unit test that creates events a few days before and after each transition and validates consistency.

Frequently Asked Questions

Why do my meetings shift by an hour on DST transitions?

Your calendar app is storing the event in UTC but displaying it in local time. When the UTC offset changes (e.g., from UTC−5 to UTC−4), the local display time can shift by an hour if the underlying recurrence rule or event storage doesn't account for the transition correctly. This is especially common if your app's tzdata is outdated or if you're syncing across multiple platforms with different tzdata versions.

How do I know which version of tzdata my calendar app is using?

For cloud services (Google Workspace, Microsoft 365), check Settings → Time or About → System Info. For desktop apps, search for "timezone" or "regional settings" in the app's preferences or your OS settings. Mobile apps rely on the OS's tzdata; check your phone's system settings. If the date is more than 60 days old, consider updating.

Can I manually adjust a recurring event that drifted on DST?

Yes, but it's not ideal. In Outlook or Google Calendar, edit the recurring event and re-save it post-transition; this forces the app to recalculate using current tzdata. Alternatively, delete the original and recreate it. For a one-time fix, you can edit that specific occurrence and move it back to the correct time, but this breaks the recurrence consistency.

Why do some timezones show as 30 minutes off on DST days?

Some regions (Nepal, parts of Australia, India) use half-hour or 45-minute UTC offsets. Older calendar apps sometimes round these to whole hours. The fix is to update your app or OS. Alternatively, use a full-hour timezone for scheduling if possible, or use UTC times and let participants convert locally.

Should I schedule recurring meetings in UTC to avoid DST bugs?

It depends. UTC avoids DST bugs but breaks the human expectation of "same clock time." A 9 AM standup in UTC becomes 4 AM or 5 AM depending on the season in some regions, which is unhelpful. A better approach is to schedule in a fixed timezone (e.g., the company's headquarters or a neutral one like UTC) and document the local times clearly, or use async meetings for teams spanning multiple DST-transition dates.

What if my calendar app never updates tzdata?

If you're on a desktop app that's no longer maintained (e.g., an old version of Thunderbird or Outlook), you're stuck until you upgrade. The only mitigation is to avoid scheduling recurring meetings during DST transition weeks, or to manually recreate meetings post-transition. For new projects, use a calendar service (Google, Microsoft, Apple) with automatic updates.

How do I test my web app's DST handling?

Use a testing library that lets you mock the system time and timezone. For JavaScript, libraries like jest-timezone-mock or jest-date-mock let you move the system clock to a DST boundary and verify that events recalculate correctly. For server-side (Node, Python, Go), temporarily change your system timezone to a DST-observing region, create events, and inspect the UTC times. Automated tests should run on every DST transition date to catch regressions.

Sources

• IANA Time Zone Database — the tzdata releases every OS and language runtime ships.
• tz-announce mailing list archive — release history showing how often zone rules change with short notice.
• RFC 5545: iCalendar — the VTIMEZONE and RRULE definitions behind recurring-meeting behaviour.
• RFC 9557: IXDTF timestamps — the standard for carrying an IANA zone name alongside an offset.
• Unicode CLDR — locale and time-zone display data used by browsers and JVMs.

Bottom Line

DST scheduling bugs are not theoretical edge cases—they affect real meetings in real organizations every March and November. The root causes are predictable: outdated tzdata, inconsistent iCalendar interpretation, and divergent recurrence-rule handling across platforms. By understanding when and why these bugs occur, checking your app's tzdata version, testing across boundaries, and knowing the workarounds, you can prevent meetings from vanishing, shifting, or becoming ambiguous. For teams managing schedules across continents, awareness of these failure modes is as crucial as keeping your system software updated.