Daylight Saving Time and the Scheduling Problems Nobody Warns You About

The Two Sundays That Quietly Break Your Calendar

Twice a year, the United States and the European Union shift their clocks on different Sundays, and for about three weeks in March and one week in late October the rest of the world has to translate every meeting time twice. This is not a small annoyance. It is the single most common reason a recurring calendar invite created in good faith ends up an hour off, a candidate is left waiting in a Zoom room for an interviewer who thinks the meeting is later, and an internal report is filed against a deadline that quietly moved while the project manager was asleep.

The standard advice — "just use UTC" — is correct in the way "just exercise more" is correct. It is true, it solves the underlying problem, and it does not survive contact with a calendar invite sent by a colleague whose default timezone is set to Paris and who clicked "every Tuesday at 3 PM" without thinking once about which Tuesdays exist on either side of the last Sunday in March. This article is the working version of the advice: what daylight saving time actually does to scheduling in 2026, where the edge cases live, and the small set of habits that get you out from under it.

What Daylight Saving Time Is, In Calendar Terms

The clock change is straightforward: in spring, local time jumps forward one hour, and the hour between 2 AM and 3 AM never happens that day. In autumn, local time falls back one hour, and the hour between 1 AM and 2 AM happens twice. The first creates a gap; the second creates an ambiguity. Both are real problems for any system that stores times in local form, because there is no canonical answer to "what is 2:30 AM on the spring-forward Sunday" (it does not exist) or "is 1:30 AM on the fall-back Sunday the first one or the second one" (you cannot tell from the string alone).

The dates are not synchronized across the world. The United States switches on the second Sunday of March and the first Sunday of November, a rule set by the Energy Policy Act of 2005 and in force since 2007. The European Union switches on the last Sunday of March and the last Sunday of October. In 2026 that means US clocks spring forward on March 8 and the EU springs forward on March 29 — a three-week window during which New York is suddenly only four hours behind London instead of five. The same thing happens in reverse in autumn: the EU falls back on October 25 in 2026, the US falls back on November 1, and for one week the offset between London and New York is again four hours instead of the usual five.

The Southern Hemisphere is on the opposite cycle. Australian states that observe DST switch in early April and early October. Brazil, which used to observe DST, abolished it in 2019. Russia abolished it in 2011 and now stays on permanent winter time. Most of Asia (including all of China, Japan, Korea, and India) has never used DST. Africa is largely a no-DST continent. Arizona and Hawaii within the US do not observe it. The end result is a global patchwork: for any given week in spring or autumn, the timezone offsets between two specific cities depend on which side of which switching date the calendar happens to be on.

Why "Just Use UTC" Is Necessary But Not Sufficient

Inside a system you control, UTC is the right storage format. Every backend logs UTC, every database column is a UTC timestamp, every cron schedule that ever crossed a timezone boundary has been rewritten at some point to use UTC after a 3 AM batch job ran twice on a fall-back Sunday or skipped entirely on a spring-forward one. None of this is controversial.

The problem is that humans do not schedule in UTC, and the systems they use to schedule do not store the timezone the human intended. When you create a calendar event in Google Calendar or Outlook, the system stores a UTC timestamp plus the timezone the event was created in. If the underlying tz database changes — and it changes every few months — the displayed local time for a future event can quietly shift. This is not theoretical. In 2007, when the US DST schedule was expanded from "first Sunday of April through last Sunday of October" to the current rule, every Outlook and Exchange installation that had not been patched showed thousands of recurring meetings an hour off for the three new weeks of DST. Microsoft published a tool to "rebase" affected events. People still ran into stragglers six months later.

The lesson is that "just use UTC" works for storage but not for intent. A recurring meeting "every Tuesday at 3 PM Eastern" is not really a UTC instant repeated weekly. It is a wall-clock commitment in a specific timezone that becomes a different UTC instant on the weeks when DST is in or out. Calendar software has to handle this for you, and it usually does — provided the underlying timezone definitions are current. The brittle case is software that stored "3 PM" as a UTC instant on the day the meeting was created, and then continued firing at that UTC instant forever, which is exactly the bug Outlook 2003 shipped and exactly the bug that lives on in countless homegrown scheduling systems today.

The IANA tz Database, Briefly

The reason any of this works at all is the IANA Time Zone Database, originally maintained by Arthur David Olson at the US National Institutes of Health and now under ICANN custodianship. It is the canonical machine-readable record of every timezone in the world and every change to every timezone since 1970, including DST rules, offset changes, and political events like Samoa's decision to skip December 30, 2011, when the country moved across the international date line.

Every operating system, every language runtime, every database you use reads this same data, either bundled or pulled at install time. When a country changes its DST rules — as Egypt, Jordan, Chile, and several others have done on relatively short notice in the last few years — a new tzdata release ships within weeks, and then it takes months for that release to propagate through OS updates, container base images, library versions, and the long tail of devices that get patched on quarterly cycles or never. A scheduled meeting in a country whose DST rule changed last month and a server whose tzdata is from last year will disagree about what time the meeting actually fires, and this is not a bug in either piece of software. It is what happens when a political decision races a software supply chain.

For the typical user the practical implication is one rule: keep your devices updated. The OS update you keep dismissing because it wants to restart is, among other things, refreshing your timezone tables.

Where People Actually Get Bitten

The pattern of real-world DST failures is narrower than the space of theoretical ones. Most of them fall into a handful of categories.

The three-week US/EU gap in March. A weekly call set up by a London-based PM to meet an LA-based engineer "at 4 PM London time" was scheduled before the US switched to DST. On March 8, the US springs forward and Los Angeles is suddenly seven hours behind London instead of eight. The London end shows up at 4 PM as planned, the LA end shows up at 9 AM as before, and one of them is now an hour off depending on which calendar made the invite. The same thing happens in reverse for the one-week gap at the end of October.

Recurring meetings that cross the spring-forward Sunday. A meeting set to recur at 2:30 AM Eastern on Sundays — perhaps a weekly batch job dressed up as a calendar event — has no place to land on the spring-forward Sunday. Different systems resolve this differently. Some skip the occurrence, some fire at 3:30 AM, some at 1:30 AM. None of them are wrong; they have just made different choices about an undefined operation.

Fall-back ambiguity in logging and SLA tracking. A log entry that says "01:45 local" on the fall-back day could refer to two different moments an hour apart. If your monitoring is correlating events across systems by local timestamp, you can get a duplicate-event window that looks like a doubled load. This is why every serious observability stack stores in UTC and converts on display.

Half-hour and quarter-hour timezones that do not move. India (UTC+5:30) and Nepal (UTC+5:45) do not observe DST. When everyone else is shifting around them, the offset to India changes twice a year while the offset within India stays the same. A US-India call that was "9 AM Eastern, 6:30 PM IST" in February becomes "9 AM Eastern, 7:30 PM IST" in March because the US end moved but the India end did not. Converting half-hour offsets by eye is also where most ad-hoc DST conversions go wrong; a quick check in a timezone converter is faster than the back-and-forth of asking a colleague what time the meeting actually is.

Cron jobs scheduled in local time. Any cron job whose schedule was written in local time and whose host is in a DST-observing zone is a future bug. The 2 AM-to-3 AM gap in spring means a job scheduled at 2:30 AM either does not fire or fires at 3:30 AM, depending on the cron implementation. The 1 AM-to-2 AM repeat in autumn means a job scheduled at 1:30 AM may fire twice. The fix is well-known — use UTC schedules — and the bug persists almost entirely because somebody, somewhere, wanted the local time to be obvious in the crontab.

A Working Set of Habits

The point of this section is not to be exhaustive. It is to be a short list that, applied consistently, eliminates the great majority of practical DST scheduling problems for a person who is not a sysadmin.

Treat the calendar's timezone field as the source of truth, not the displayed time. When you create a recurring meeting, the timezone you select determines how the meeting behaves across DST transitions. "Every Tuesday at 3 PM, US Eastern" is unambiguous and will adjust correctly for the European participants when the US switches. "Every Tuesday at 3 PM" with no timezone, or with the wrong timezone because your calendar defaulted, is the bug.

When scheduling across hemispheres, name two cities explicitly in the invite description. "Wednesday 14:00 London / Thursday 08:00 Sydney" makes the intent legible even when the underlying timezone math is going to shift across multiple DST transitions before the meeting happens. The redundancy costs nothing and surfaces the gap before the meeting, not during it.

Convert with a tool, not with mental math, anytime a half-hour timezone is involved. India, Newfoundland, parts of Australia, and Nepal all have non-integer offsets. Subtracting "five and a half hours" by eye is where errors happen. A quick check is what tools like the timezone converter linked above are for; the cost of using one is roughly zero, and the cost of being wrong is a missed call.

If you run servers, schedule in UTC and let local display be a presentation concern. Every cron job, every Kubernetes CronJob, every cloud scheduler should be configured in UTC. The reasoning is the same as for databases storing UTC timestamps: it eliminates an entire category of failure that is genuinely hard to test for, because you cannot easily reproduce a future DST transition in a test environment without time-travel infrastructure.

Pay attention to the gap weeks. The two windows when the US and EU are out of sync — roughly mid-to-late March and the week before the US falls back — are when DST scheduling errors cluster. If you have a critical recurring meeting that crosses the Atlantic, verify it explicitly on the first instance after each transition. It takes thirty seconds and will catch every gap-week bug before it costs an hour of someone else's day.

The Policy Question Hanging Over All of This

It is worth noting that the underlying policy is not stable. The European Parliament voted in 2019 to abolish seasonal clock changes, with implementation deferred to member states and then quietly postponed indefinitely. The US Senate unanimously passed the Sunshine Protection Act in March 2022, which would have made DST permanent year-round; the bill died in the House and has been reintroduced in subsequent sessions without passage. Mexico abolished DST for most of the country in 2022. Several US states have passed legislation that would put them on permanent DST or permanent standard time pending federal action that has not come.

The likely future, on a horizon of several years, is that some jurisdictions stop switching while others continue. The patchwork will get worse before it gets better. Whatever the policy outcome, the operational discipline is the same as it has always been: store in UTC, schedule with explicit timezones, keep your timezone tables updated, and check the conversion when half-hour offsets or gap weeks are involved. The clock politics will change. The scheduling habits will not.