Does this affect places that do not observe daylight saving time?

No. Regions that stay on a single fixed offset year-round (much of Arizona, Hawaii, and many countries near the equator) have no transition day and no missing or repeated hour to account for.

Is the "missing hour" the same every year?

The one-hour size of the shift is consistent almost everywhere that observes DST, but the calendar date it happens on can change year to year and jurisdiction to jurisdiction, and some countries have discontinued or reinstated DST entirely, so the applicable rule is date- and location-specific.

Which WhenMath tool should I use to compare a fixed offset against a DST-aware calculation?

The DST Transition Comparator runs the same two clock readings both ways, showing the naive clock-subtraction result next to the real elapsed-time result, so the size of the discrepancy is visible directly.

How Daylight Saving Transitions Distort Elapsed-Time Math

Twice a year, a day does not have 24 hours, and clock-based elapsed-time math that ignores this can be off by exactly one hour.

Download PDF

Daylight saving transitions insert a 23-hour or 25-hour day into an otherwise regular calendar, because clocks jump forward or fall back by one hour at a fixed local moment. Any calculation that treats every day as exactly 24 hours, or every "9 AM to 5 PM" as exactly 8 hours, will be wrong by one hour on the specific days a transition occurs in the relevant time zone, even though the calculation would be correct on every other day of the year.

A spring-forward day loses one real hour and a fall-back day gains one, even though both read as ordinary 24-hour days on a calendar.

Two different questions that DST transitions affect differently

"How much real elapsed time passed between two clock readings" and "what does the clock say now" are different questions that DST transitions pull apart. A shift that clocks in at 9 AM the day before a spring-forward transition and clocks out at 5 PM the next day covers one fewer real hour than the plain clock-time subtraction suggests, because one of those hours was skipped entirely by the clock jump. A timezone-aware calculation resolves this correctly by converting through an absolute instant rather than subtracting clock readings directly.

Ambiguous and nonexistent local times

The fall-back transition creates a genuinely ambiguous local time. "1:30 AM" occurs twice on that day, once before the clocks repeat and once after, and a bare timestamp without an explicit earlier/later disambiguation cannot say which one is meant. The spring-forward transition creates the opposite problem, a local time (2:30 AM in a typical one-hour-forward jump) that never occurs at all that day. Both cases require an explicit resolution rule, not a guess.

What WhenMath's engines do about it

Engines that compute elapsed real time across a potential DST boundary (rather than pure calendar-date subtraction) resolve through WhenMath's time-zone-aware temporal layer, which detects nonexistent and ambiguous local times explicitly and states in the result when a DST transition affected the outcome, rather than silently returning a plain 24-hours-per-day answer.

Key takeaway. Any elapsed-time calculation that crosses a DST transition boundary in a zone that observes DST needs to account for the missing or repeated hour explicitly. A plain clock-time subtraction across that boundary is off by exactly one hour.

Frequently asked

Does this affect places that do not observe daylight saving time?: No. Regions that stay on a single fixed offset year-round (much of Arizona, Hawaii, and many countries near the equator) have no transition day and no missing or repeated hour to account for.
Is the "missing hour" the same every year?: The one-hour size of the shift is consistent almost everywhere that observes DST, but the calendar date it happens on can change year to year and jurisdiction to jurisdiction, and some countries have discontinued or reinstated DST entirely, so the applicable rule is date- and location-specific.
Which WhenMath tool should I use to compare a fixed offset against a DST-aware calculation?: The DST Transition Comparator runs the same two clock readings both ways, showing the naive clock-subtraction result next to the real elapsed-time result, so the size of the discrepancy is visible directly.

Related engines

DST Transition Comparator -- List every offset transition a time zone makes within a date range.
Paid vs Elapsed Time Calculator -- Separate real, DST-aware elapsed time in a zone from paid time after unpaid breaks.
Time Zone Converter -- Convert a specific local date and time from one IANA zone to another.

Last updated 2026-09-04

Back to Resources