Fifty years of DST changes: a tour of the IANA tzdata history

Most software developers treat DST schedules as static knowledge. They aren’t. The IANA tzdata database — the canonical source for time-zone rules worldwide — has shipped multiple updates every year for decades. Between 1990 and 2024 the database recorded rule changes for at least 39 different national or sub-national entities. This piece walks through the biggest changes, why they happened, and what they teach about scheduling-system design.

What “a rule change” means

IANA tzdata stores time-zone rules as pairs of (effective period, offset/DST behaviour). A rule change adds a new entry — “starting on date X, this zone no longer observes DST” — and leaves the historical rules intact. Systems that depend on accurate scheduling need to load updates regularly; one that loads a 2010 snapshot of tzdata will get every DST-aware computation wrong for any post-2010 rule change.

Selected high-impact changes

Russia (2011, 2014)

In 2011 the Russian Federation moved permanently to summer time, eliminating clock changes. By 2014 the policy reversed — Russia switched permanently to standard time (winter time). Two rule changes in three years for an 11-timezone country affected every Russian-facing service. Outlook, exchange servers, and database scheduled jobs misfired in waves both years.

Brazil (2019)

Brazil ended DST in late 2019 after observing it for ~80 years. The decision was made on energy-policy grounds — the savings DST historically provided had eroded as peak-load patterns shifted. Roughly 70 million people in the affected southern and southeastern states wake up to the same offset year-round now.

Egypt (2010-2015, on-and-off)

Egypt cancelled DST in 2010, reinstated it for the 2014-2015 season (with a notable mid-Ramadan suspension), then cancelled it again. The 2014 case is a famous software-rollout exemplar: the announcement of the rule change came so close to the spring-forward date that many systems didn’t pick it up; Egyptian users saw their phones show times 1-2 hours off for days.

Samoa (2011)

Samoa moved from UTC-11 to UTC+13 by skipping 2011-12-30 entirely. The country effectively crossed the international date line on a Thursday morning, jumping straight to Saturday. Trade and shipping with Australia and New Zealand drove the change; Samoan businesses previously had a 21-hour business-day mismatch with their major trading partners.

Türkiye / Turkey (2016)

Turkey abandoned DST in 2016, fixing the country at UTC+3 year-round. Cited reasons: energy savings questionable, morning darkness in winter unpopular. Software vendors scrambled to push patches before the autumn fall-back date that no longer existed.

Morocco (2018+)

Morocco switched to permanent DST in 2018 (UTC+1 year-round, suspended each year during Ramadan when the country reverts to UTC+0 for the month). The Ramadan-driven double-change every year is one of the most complex rules in IANA tzdata — its date shifts by ~11 days annually relative to the Gregorian calendar.

EU summer-time directive (2018-2021, still pending)

The European Commission proposed ending DST across the EU in 2018. The European Parliament approved in 2019 with 2021 as the implementation date. Member-state agreement on which time to permanently observe (their summer time or their standard time) was never reached; the change has not happened. As of 2026 the EU still observes DST, though the political consensus to end it persists.

US: Sunshine Protection Act (2022)

The US Senate unanimously passed a bill to make DST permanent in March 2022. The House did not take it up. The bill was reintroduced in 2023 and again did not pass. The US continues to spring forward and fall back.

The volume problem

Counting major rule changes by decade (excerpted from IANA tzdata NEWS file):

The trend is roughly steady: 5-10 meaningful rule changes per year worldwide. A system that doesn’t refresh tzdata annually will be wrong for ~3-5% of the world’s population by a 5-year-old database.

What this costs in practice

Three categories of breakage observed across IT post-mortems on outdated-tzdata incidents:

• Calendars and meetings. Cross-zone meeting invites display the wrong local time. The attendee with the outdated phone misses the call.
• Database timestamps and reporting.Cron jobs fire an hour early or late. Daily-aggregate reports include or exclude transactions across the phantom DST boundary. Subtle but expensive in financial reconciliation.
• API rate-limit windows and scheduled jobs.Anything that defines “midnight in zone X” gets it wrong for an hour. SaaS billing, log-rotation schedules, and similar back-end work fails silently.

What to do about it

1. Use the IANA database, not abbreviations.Store zones as America/New_York, notEST. Abbreviations don’t encode rule changes; IANA names do.
2. Keep tzdata updated. Operating systems ship tzdata updates monthly or quarterly. Make sure containers, function runtimes, and bundled apps actually receive them.
3. Re-render scheduled events on rule change.A meeting scheduled in 2024 to repeat “every Monday at 2pm New York time” correctly tracks DST. A meeting scheduled in 2024 to repeat “every Monday at 2pm EST” (the abbreviation) breaks twice a year.
4. Test with adversarial dates.The three weeks each spring when US and EU DST schedules don’t align, the dates a country recently changed its rules, the leap-second-overlap if present. Real test fixtures include these.

For practical cross-zone scheduling, use our time zone converter (uses the browser’s tzdata) and meeting planner (handles DST mismatches automatically).

Sources

IANA tzdata database NEWS file (Eggert et al., 1986-2024); timeanddate.com archived DST policy reports; Microsoft Daylight Saving Time and Time Zone bulletins; ICAO notices on aeronautical time references.