Does Daylight Saving Time Affect Sleep? The Real Effect Is Minutes. The Error in Your Data Can Be an Hour

The UK and the EU put their clocks back an hour on 25 October. The US and Canada follow on 1 November, the morning after Halloween. For a week or two, sleep apps will show longer nights, earlier mornings, irregular bedtimes and the occasional alarming readiness score.

Some of that is real. Much of it is not. Studies covering more than 18 million nights of sleep put the real change in sleep at minutes, mostly in timing. An app that calculates sleep from wall-clock times gets the night wrong by a full hour, which is three times the size of the effect it is reporting.

This is what the clock change does to the body, what it does to the data, and how to tell the two apart.

How much does the clock change actually affect sleep?

The best evidence now comes from wearables, because they record the same people before and after each change:

And from population health records, where the spring change shows up and the autumn change largely does not:

• Heart attacks: in a Michigan registry, heart attacks needing treatment were 24% more frequent on the Monday after the spring change, and 21% less frequent on the Tuesday after the autumn change. Total heart attacks across each week did not change, suggesting the shift moves events earlier or later rather than causing new ones [5].
• Road deaths: across 732,835 fatal US crashes, risk rose about 6% in the week after the spring change, and more than 8% in the western edges of time zones. The autumn week showed no overall change [6].

Read together, the autumn change is mostly a timing shift: one somewhat longer night, earlier waking by the clock for a few days, more activity in the morning and less in the evening, and a week of less regular sleep. Its effect on sleep duration is a fraction of a percent. The spring change genuinely costs sleep, and the cost is visible in population statistics for about a week.

One more finding matters for anyone reading individual data. In the Fitbit preprint, people whose sleep changed a lot after the transition were typically back in their usual range within about two nights, and people in Arizona, whose clocks did not change, showed the same two-night pattern [3]. Most of what an individual sees the morning after a clock change is ordinary night-to-night variation, not the clock change.

Why sleep data can be wrong by an hour

Now take one night. A user in London goes to bed at 23:00 on Saturday 24 October and gets up at 07:00 on Sunday by the clock on the wall. At 02:00 the clocks went back to 01:00, so the night lasted 9 hours of real time.

The spring night is the mirror image. Bed at 23:00, up at 07:00, but the clocks jumped from 01:00 to 02:00, so the night was 7 hours. Wall-clock subtraction reports 8: it hides exactly the hour the user lost.

None of this is hypothetical. After the US change in November 2022, Fitbit users saw sleep times shifted by an hour, which Fitbit acknowledged and said usually corrected itself after the next midnight [7]. Researchers at Duke left Fitbit sleep data out of their 2026 study of daylight saving time altogether, citing unreliable sleep tracking around the transitions [4]. If a research team with the raw data cannot trust the numbers, a readiness score built on them deserves the same caution.

The deeper cause is how each platform stores time: some keep the absolute instant, some keep only the local clock, and only some keep the time zone. We compared every major platform in which day does last night’s sleep belong to.

The error does not end on Sunday

A bad night is one data point. The damage is in everything computed from it:

• Baselines. A 7-day average carries the 25-hour day for a week, and a 28-day baseline for a month. A night recorded an hour short drags down a personal sleep baseline exactly when the user’s real sleep was slightly longer.
• Regularity and timing. Sleep regularity measures compare bedtimes and wake times across days, usually in local time. That is the right clock for most purposes, because people live by it, but on the transition night it registers a one-hour jump that the body did not make. WHOOP’s consistency score fell 6.1% on the autumn transition [1]; part of that is behaviour, and part is arithmetic.
• Alerts. In Oura’s data, HRV moved 0.74% and resting heart rate 0.35% in the week after the autumn change [2]. Those are far inside normal day-to-day variation: across 92,457 Fitbit users, resting heart rate varied by about 3 bpm day to day within the same person [8]. An alert that fires this week is more likely to be reacting to a timestamp than to the user.
• Schedules. A reminder set for 01:30 fires twice on the autumn night and not at all in spring. A daily job set for 02:00 local time is skipped in spring. Two regions changing on different dates also changes the gap between them: between 25 October and 1 November, London is four hours ahead of New York instead of five.
• Comparisons across countries. The world does not change on one date or in one direction. Europe went back on 25 October, North America goes back on 1 November, New Zealand and south-east Australia moved forward in September and October, and Arizona, Hawaii and most of Asia do not change at all. Australia’s Lord Howe Island moves by 30 minutes. A global week-over-week dashboard this fortnight mixes all of them.

Test your app before 1 November

Whether a product has this problem takes minutes to find out. Feed it these nights, with the bedtime and wake time in local time, and compare its answers with the correct ones:

If every row comes back as 8 hours, durations are being calculated on the wall clock. Two more checks catch the subtler bugs: hourly charts for Sunday 25 October in London should have 25 buckets, not 24 with one doubled, and a sample stamped 01:30 that morning is ambiguous, because it happened twice, at 00:30 and 01:30 UTC. Code that receives a local time without an offset cannot tell which.

The bug is easy to write by accident. In Python, subtracting two times that share a time zone ignores the clock change, by design:

from datetime import datetime, timezone
from zoneinfo import ZoneInfo

london = ZoneInfo("Europe/London")
bed = datetime(2026, 10, 24, 23, 0, tzinfo=london)
wake = datetime(2026, 10, 25, 7, 0, tzinfo=london)

wake - bed  # 8:00:00, wall-clock difference

wake.astimezone(timezone.utc) - bed.astimezone(timezone.utc)  # 9:00:00, real elapsed time

Python’s documentation describes this: when both times have the same time zone attribute, it is ignored and the difference is computed on the local times [10]. JavaScript Date arithmetic uses absolute time and gets this right, but only if each timestamp was parsed with its offset. A local time stored as a string without one has already lost the information, and no library can recover it.

How to measure the real effect in your own users

The research above uses three techniques any product team can copy:

1. Compare like with like. WHOOP compared each transition night with the same weekday in the four weeks before and after [1]. Comparing Sunday with Saturday measures the weekend, not the clock change.
2. Use people whose clocks did not change as a control. Both All of Us studies compared Colorado, New Mexico and Utah with Arizona, which sits in the same time zone but does not change its clocks [3][4]. The change in the changing group, minus the change in the control group, is the effect of the clock. With users in several countries you usually have a control group already.
3. Measure duration in absolute time and timing in local time. How long someone slept is a question about elapsed time. When they slept is a question about the clock they live by. Mixing the two produces most of the errors in the table above.

Then watch for things that coincide with the change. In 2020, WHOOP’s autumn transition night was also the night after Halloween, and alcohol use that night rose 9.5% [1]. In 2026 the US change falls on the same night again, so US data from this weekend will mix the clock change with Halloween. Europe’s change on 25 October has no such overlap.

What to tell users

The honest message is that the clock changed, the body takes a few days to follow, and one unusual night means little. Something like “The clocks changed this weekend. It can take a few days for your sleep to settle, so we won’t read much into tonight” is more accurate than a low recovery score, and it builds more trust than silence.

The clock change is real, but it is smaller than most sleep data makes it look. The evidence says minutes of sleep, a few days of shifted timing and a measurable cost in spring. An app that subtracts clock times reports an hour. The first is worth telling users about; the second is worth fixing before 1 November.