Field note 13 · Calendar checks
One Night, Two Dates: Reading Wearable Sleep Around Clock Changes
Midnight, travel and clock changes can give one observation several date labels. Here is how to check the interval before changing the diary.
Start with the interval, not the date on the card
A sleep record can begin on Saturday, end on Sunday, arrive on Monday and still be shown on Tuesday. Those dates answer different questions. Before correcting a diary or interpreting a weekly change, establish which question each date actually answers.
In a technical review of Nutrinaut’s iOS data-handling code, we traced measurement endpoints, provider-assigned days, diary labels and snapshot updates separately. They are not interchangeable. This guide turns that distinction into a practical check for midnight, travel and seasonal clock changes. The examples below are invented calendar exercises, not individual sleep histories or device-validation experiments.
Keep these four clocks separate
| Clock or label | What it describes | What it does not establish |
|---|---|---|
| Measurement interval | When the recorded observation began and ended, with its time zone or UTC offset. | That every minute between the endpoints was classified as sleep. |
| Provider’s day | The calendar day assigned by the originating device or service. | That every app uses the same rule for grouping an overnight interval. |
| Diary’s day | The date under which the destination displays the observation. | The time the measurement happened or arrived. |
| Arrival or update time | When data were imported, or when a summary was recalculated. Keep these two times separate when both are available. | That a new night was measured at that moment. |
A disagreement between labels is a reason to inspect the interval, not immediate proof of a broken record. In the inspected iOS implementation, sleep reporting uses a noon-to-noon window. A calendar label therefore need not mean “everything between midnight and the next midnight.” Other sources and versions can use different windows.
Example 1: one moment, two calendar dates
Demonstration: 00:30 in Madrid on 10 October 2026 is 22:30 UTC on 9 October. Both labels refer to the same instant; Madrid is two hours ahead of UTC on that date.
If one screen prints the local date and another derives its date from UTC, “10 October” versus “9 October” can be entirely consistent. Compare the complete timestamp and offset before moving the observation to another day. A date without its time-zone context cannot settle the question.
Example 2: eight hours on the clock need not mean eight elapsed hours
Spain’s official calendar sets the 2026 changes for 29 March and 25 October. In Madrid, clocks advance from 02:00 to 03:00 in March and move back from 03:00 to 02:00 in October. The affected calendar days contain 23 and 25 elapsed hours respectively. Official BOE calendar.
Spring: 7 elapsed hours
Synthetic interval: Madrid, 28 March 2026 at 23:00 (UTC+01:00) to 29 March at 07:00 (UTC+02:00).
22:00 UTC → 05:00 UTC = 7 hours
The local clock labels span eight hours, but the forward change skips one hour.
Autumn: 9 elapsed hours
Synthetic interval: Madrid, 24 October 2026 at 23:00 (UTC+02:00) to 25 October at 07:00 (UTC+01:00).
21:00 UTC → 06:00 UTC = 9 hours
The local labels again span eight hours, but the repeated hour adds an elapsed hour.
These are interval lengths, not measured sleep totals. A device may exclude awake periods or define its sleep summary differently. Do not “fix” a displayed sleep total by adding or removing an hour solely because the clocks changed.
On the autumn-change morning, a plain label such as 02:30 occurs twice in Madrid. The offset distinguishes the two occurrences: UTC+02:00 versus UTC+01:00. Without that detail, do not pretend an exact instant can always be recovered.
Try the repeated hour before 25 October
On the Madrid autumn-change morning, an interval can start in the first 02:00 hour and finish in the second. A plain subtraction of the clock labels misses the change. Keep both endpoint offsets rather than adding an hour to every record on that date.
Offsets supplied: 90 elapsed minutes
Synthetic interval: 25 October 2026, 02:15 UTC+02:00 → 02:45 UTC+01:00.
00:15 UTC → 01:45 UTC = 90 minutes
The wall-clock labels differ by 30 minutes, while the instants are 90 minutes apart. Both statements describe this example correctly; they answer different questions.
Offsets absent: do not invent the answer
Synthetic labels: 25 October 2026, 02:15 → 02:45 in the repeated Madrid hour, with no endpoint offsets or fold information.
Those labels alone do not identify which occurrence of each time was intended. Preserve the ambiguity. Obtain the original offset, a UTC timestamp or equivalent source detail before reporting an exact elapsed duration.
Download and inspect two teaching cases
Download the explicit-offset CSV
Download the deliberately missing-offset CSV
Each file contains one invented exercise-duration row, not a sleep measurement, workout recommendation or user record. They are separate files so you can inspect the valid case before testing the incomplete one.
- Open Data Forensics Lab and choose the explicit-offset file. Check that its 90-minute duration agrees with elapsed time, not the 30-minute wall-clock difference.
- Choose the missing-offset file next. The lab should reject its timestamp format; it cannot resolve which repeated hour was intended.
- Do not add your browser’s current time zone to make the incomplete case pass. Obtain the original offset or UTC instant instead.
The lab runs locally in your browser. Passing its timestamp check establishes consistency of these supplied fields, not the accuracy or completeness of an original sensor record.
For sleep, make one further distinction: the elapsed interval is not necessarily all time asleep. Use the sleep coverage visual to keep the night window, in-bed category and classified stages separate.
A late arrival is not an extra night
One illustrative timeline
- Observation: the autumn example starts on 24 October and ends on 25 October.
- Provider label: suppose the source assigns it to 25 October, the ending day.
- Diary label: the destination also displays it under 25 October.
- Late import: the record arrives on 26 October; the dashboard refreshes on 27 October.
There is still one observation interval, not three nights. The import and refresh dates explain data handling; they do not add measurements.
The same rule applies to a last-known value. If its actual endpoints belong to an earlier night, a newly refreshed card does not make it current. If the endpoints are unavailable, write “observation date unverified” rather than inferring the night from the refresh time. The wearable source checklist covers missing records and last-known values in more detail.
After travel, do not use today’s time zone to guess yesterday’s
Your phone’s current zone does not prove the zone in which a historical observation was recorded. A timestamp can be rendered under a new zone after travel; the underlying instant and the displayed calendar label are different things.
For an overnight trip, preserve the original start and end timestamps with their offsets where available. Check whether the source assigns a day by the start, end or another reporting rule. If that rule is not documented or visible, keep it unresolved. Do not merge or delete two entries merely because their date labels differ.
The five-minute date check
- Open the source observation. Record the interval and the exact category: sleep, time in bed or another summary.
- Copy the time-zone detail. Keep the zone name or UTC offsets at both endpoints. Mark missing information explicitly.
- Name the grouping rule. Which day did the provider assign, and which day does the diary display?
- Separate arrival from measurement. Note import and refresh times without counting either as another observation.
- Choose the comparison. Compare compatible intervals and definitions. Annotate travel, a clock change or an unresolved date rather than silently correcting it.
If a difference remains, a useful private support report contains the source, category, endpoints, zone, provider day and diary day. That is more actionable than “Sunday’s score is wrong.” For a weekly view, the seven-night sleep planner can organise the durations you have checked; it cannot establish the provenance of an imported record.
The aim is modest but important: know which night a number describes before asking what it means. Calendar consistency alone does not validate a sensor, diagnose sleep problems or establish recovery.
Sources and scope
Prepared on 10 October 2026; repeated-hour CSV exercise added and checked on 15 October 2026. The source-code review informed the distinctions above; it does not establish every historical app version’s behaviour. Calendar examples were checked with explicit Europe/Madrid time-zone conversions. They are demonstrations, not user data, clinical research or an independent product review.
- Spain’s BOE: official 2022–2026 summertime dates and clock-change rules.
- European Commission: current EU summertime arrangements.
- European Commission communication 2021/C 149/01, official BOE mirror — the EU 2022–2026 schedule, including 25 October 2026 at 01:00 UTC.
- Nutrinaut Connections & Data Guide: supported data paths and their limits.
Analysis and drafting were AI-assisted. Eugene Blago is responsible for the published material; this is not independent expert review. Found a factual or arithmetic error? Send the page URL to [email protected]. See our corrections policy.