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.
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. 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.