Skip to main content
Basics

Daylight Saving Time - How Clock Changes Affect Global Coordination

What Is Daylight Saving Time?

Daylight Saving Time (DST) is the practice of advancing clocks by one hour during warmer months so that evenings have more daylight. In spring, clocks "spring forward" by one hour, and in autumn they "fall back" to standard time. The concept was first seriously proposed by George Vernon Hudson in 1895 and was widely adopted during World War I as an energy-saving measure.

Today, roughly 70 countries observe some form of DST, though the practice is concentrated in North America and Europe. Most of Africa, Asia, and South America do not change their clocks. Countries near the equator see little variation in daylight hours throughout the year, making DST unnecessary. Japan, China, and India are notable examples of major economies that operate on fixed standard time year-round.

When Do Transitions Occur?

The United States and Canada begin DST on the second Sunday of March at 2:00 AM local time and end it on the first Sunday of November. The European Union transitions on the last Sunday of March and the last Sunday of October, with changes occurring at 1:00 AM UTC simultaneously across all member states. This means there are several weeks each year when the time difference between North America and Europe is one hour different from the usual offset.

Southern hemisphere countries that observe DST do so on the opposite schedule. Australia begins DST in early October and ends it in early April. New Zealand starts in late September and finishes in early April. This creates a period where the time difference between Sydney and London swings by two hours compared to their midwinter offset, because one city is in summer time while the other is in standard time.

The exact transition rules change over time. The United States extended DST by several weeks in 2007 under the Energy Policy Act of 2005. Any software handling time conversions must use an up-to-date copy of the IANA time zone database to reflect the current rules for each jurisdiction.

Impact on International Scheduling

DST transitions are a leading cause of missed international meetings. A recurring weekly call between Tokyo and London that works perfectly for months will suddenly be off by an hour when the UK shifts to British Summer Time. The meeting organizer may not realize the change has occurred until someone joins an hour late or an hour early.

The safest approach is to schedule recurring international meetings using a fixed UTC time rather than a local time. If a meeting is set for 09:00 UTC every Tuesday, it will always be 09:00 UTC regardless of DST changes. Participants in DST-observing regions will see the meeting shift by one hour in their local calendar, but the actual meeting time remains consistent. Calendar applications that support time zone-aware scheduling handle this automatically when the event is created with a UTC anchor.

The Movement to Abolish DST

Growing evidence suggests that the biannual clock change causes measurable harm. Studies have documented increases in heart attacks, traffic accidents, and workplace injuries in the days following the spring transition. Sleep researchers argue that the abrupt one-hour shift disrupts circadian rhythms, with effects lasting up to two weeks for some individuals.

Several jurisdictions have moved to abolish DST. The European Union voted in 2019 to end mandatory clock changes, though implementation has been delayed. In the United States, the Sunshine Protection Act passed the Senate in 2022 proposing permanent DST (staying on summer time year-round), but it did not advance in the House. Arizona and Hawaii already do not observe DST. As more regions consider abolition, the patchwork of rules will likely become even more complex during the transition period.

Considerations for Software Developers

DST creates subtle bugs in software that handles time. A day is not always 24 hours long: the spring-forward day has only 23 hours, and the fall-back day has 25. Code that assumes a day is exactly 86,400 seconds will produce incorrect results twice a year. Similarly, the local time 2:30 AM does not exist on the spring-forward day, and the local time 1:30 AM occurs twice on the fall-back day.

The standard advice for developers is to store all timestamps in UTC and convert to local time only at the presentation layer. When displaying future events, store the intended local time along with the IANA time zone identifier (not just the UTC offset), so that if DST rules change before the event occurs, the system can recalculate the correct UTC equivalent. Libraries like Luxon, date-fns-tz, and Java's java.time package handle these edge cases correctly when used with current time zone data.

XB!LINE

Was this article helpful?

Related Articles