[iOS] [NOOP v12.1.0] Sleep Not Detected on October 25 – Possible DST/Timezone Bug #2852

Activity

1. Sammy-2213

   added

   bugSomething isn't workingSomething isn't working

   on Oct 25, 2026
2. ryanbr commented on Oct 25, 2026

   

   ryanbr

   on Oct 25, 2026

   Owner

   More actions

   Thank you for the minimised log, and for saying the DST link was unconfirmed rather than asserting it. Two answers below: what your night is not, and the one line that will say what it is.

   DST is not the cause of your missing night

   Your own report rules it out before any code does: you also see NO-NIGHT on October 20 and October 23, and neither is a transition day. Anything that only happens when the clocks move cannot explain those.

   The code agrees. The local-day window maths is daylight-saving-aware and pinned by a shared cross-platform oracle that includes both a 23-hour and a 25-hour day (America/New_York 2025-03-09 at 82,800 s and 2025-11-02 at 90,000 s), so a 25-hour Sunday produces a 25-hour day window on both platforms.

   Your window=38h is also exactly what it should be: the read is 30 hours of lookback plus however far into the day you are, and 30 + 8 puts your log at about 08:00 local. Nothing about it is short.

   Your question did surface a real DST defect, though, somewhere else

   Worth saying plainly because it is yours: asking the question sent me to that maths, and the sleep read window's END is computed with a fixed day length.

   IntelligenceEngine.sleepReadWindowEnd takes the day's end as dayStart + 86400. On a 25-hour day that is one hour BEFORE local midnight, and on a 23-hour day it is one hour INTO the next day. The repository already has the correct version of this exact function, LocalDayWindows.sleepReadWindowEnd, which takes the real next local day start and is itself tested against 2025-11-02, the 25-hour day. It has test callers only; all three production call sites use the arithmetic one.

   So on a transition day a past day's read window is off by an hour at its far end. That is a real bug and it is being handled separately. It is NOT what emptied your night, for three reasons: the branch that uses the fixed length only runs for a day that is already over, your log was taken during October 25 and so took the other branch (window=38h proves it), and it cannot touch October 20 or 23 at all.

   What staged-none actually says

   That token is specific. It means motion WAS present and the stager still produced nothing, which the code's own comment calls the case most worth investigating. Your counts bear that out: 70,351 heart-rate, 45,535 R-R and 69,851 gravity samples is not a thin night.

   Two known mechanisms produce exactly this, and they need different work:

   1. Fragmentation by gravity dropouts (ble: extract dataRangeOldestUnix into WhoopProtocol.DataRange + pin the aligned-scan protection (#286 follow-up) #308). The in-bed spine fragments at every gravity gap over the tolerance, then every fragment under the 60-minute floor is dropped, so a real six-hour night can collapse to nothing. A rescue bridge exists but is gated on the night looking SPARSE, measured as gravity SPAN against heart-rate span rather than sample count.
   2. Fragmented to nothing on a DENSE night (Last night sleep not captured. Same results as previous day. Also for effort. #1937). The same collapse on a night whose gravity coverage is good, where that sparse gate therefore declines the rescue. A real capture had five runs, 298 minutes of detected sleep, every one about a minute short of the floor, and the night vanished.

   Both are survivable; which one you are in decides what changes.

   The one line that tells them apart

   You already have the right Test Centre profile on, Sleep and Rest, which is exactly what enables these traces, so this should already be in your log rather than needing a new capture. Please paste just the sparseBridge lines for one affected day:

   sparseBridge sparse=<true|false> fragmentedToNothing=<true|false> gapMin=90 runsBefore=<n> runsAfter=<n>
   

   plus any per-pair lines beside it, which each carry one of bridged, gapTooLong, hrOutOfBand, overlap or activeTooLong, and the [sleep] hr-only gate line if one is present.

   That is counts and tokens only: no timestamps, no sensor values, nothing identifying. Please do NOT attach your export here, and no need to post the raw streams.

   What each answer would mean:

   • runsBefore=0: no sleep run was built at all, so the question moves upstream to stillness classification and the heart-rate baseline, not to the bridge.
   • runsBefore of several with runsAfter the same, and a per-pair gapTooLong or hrOutOfBand: the rescue was attempted and refused, and the refusing rule is named.
   • sparse=false fragmentedToNothing=false with several runs: the rescue was never enabled on a night that needed it, which is the Last night sleep not captured. Same results as previous day. Also for effort. #1937 shape one step further out.

   If you can paste the same lines for October 20 and October 23, that is more useful than three separate reports: identical trace shapes across all three mean one cause rather than three, and that is the difference between one change and an investigation per night.
3. Sammy-2213 commented on Oct 25, 2026

   

   Sammy-2213

   on Oct 25, 2026 via email

   Author

   More actions

   ryanbr, I extracted the relevant diagnostic information from my latest Sleep and Rest export (October 25, 16:03). I’ve excluded personal identifiers, exact measurement timestamps, and raw health data. October 25 – sparseBridge trace [sleep] gate run=-1 spanS=0 DROPPED gate=sparseBridge sparse=true fragmentedToNothing=false gapMin=90 runsBefore=1 runsAfter=1 [sleep] gate run=-1 spanS=0 DROPPED gate=sparseBridge no candidate pairs (one sleep run, or fragments split by consecutive active runs) Important new finding The latest export now contains successful sleep calculations for two nights that previously returned NO-NIGHT. October 23: sleep day=2026-10-23 totalSleepMin=385 stages=123+163+100=385 eff=0.97 matched=1 source=computed October 25: sleep day=2026-10-25 totalSleepMin=463 stages=100+185+178=463 eff=0.97 matched=1 source=computed October 23 – detection summary [sleep] sleep-detect summary: sleepRuns=2 droppedMinSleep=0 kept=2 detectedSpanMin=1908 survivingSpanMin=861 sparse=false October 20 – still missing sleep-detect day=2026-10-20 NO-NIGHT reason=staged-none I couldn’t identify a corresponding detailed sparseBridge trace for October 20 or any [sleep] hr-only gate lines. My observations October 23 and 25 initially returned NO-NIGHT but were successfully calculated in the latest export. October 25 shows sparse=true, fragmentedToNothing=false, runsBefore=1 and runsAfter=1, with no candidate pairs. October 23 successfully produced sleep results with sparse=false and two retained sleep runs. October 20 remains undetected. Could this indicate an issue with data availability, synchronization, caching, or recalculation rather than the fragmentation mechanisms you described? Is there anything else specific I can extract to help narrow this down without sharing my complete diagnostic files? Thanks again for looking into this!SamOn 25 Oct 2026, at 15:37, Fanboynz ***@***.***> wrote:ryanbr left a comment (ryanbr/noop#2852) Thank you for the minimised log, and for saying the DST link was unconfirmed rather than asserting it. Two answers below: what your night is not, and the one line that will say what it is. DST is not the cause of your missing night Your own report rules it out before any code does: you also see NO-NIGHT on October 20 and October 23, and neither is a transition day. Anything that only happens when the clocks move cannot explain those. The code agrees. The local-day window maths is daylight-saving-aware and pinned by a shared cross-platform oracle that includes both a 23-hour and a 25-hour day (America/New_York 2025-03-09 at 82,800 s and 2025-11-02 at 90,000 s), so a 25-hour Sunday produces a 25-hour day window on both platforms. Your window=38h is also exactly what it should be: the read is 30 hours of lookback plus however far into the day you are, and 30 + 8 puts your log at about 08:00 local. Nothing about it is short. Your question did surface a real DST defect, though, somewhere else Worth saying plainly because it is yours: asking the question sent me to that maths, and the sleep read window's END is computed with a fixed day length. IntelligenceEngine.sleepReadWindowEnd takes the day's end as dayStart + 86400. On a 25-hour day that is one hour BEFORE local midnight, and on a 23-hour day it is one hour INTO the next day. The repository already has the correct version of this exact function, LocalDayWindows.sleepReadWindowEnd, which takes the real next local day start and is itself tested against 2025-11-02, the 25-hour day. It has test callers only; all three production call sites use the arithmetic one. So on a transition day a past day's read window is off by an hour at its far end. That is a real bug and it is being handled separately. It is NOT what emptied your night, for three reasons: the branch that uses the fixed length only runs for a day that is already over, your log was taken during October 25 and so took the other branch (window=38h proves it), and it cannot touch October 20 or 23 at all. What staged-none actually says That token is specific. It means motion WAS present and the stager still produced nothing, which the code's own comment calls the case most worth investigating. Your counts bear that out: 70,351 heart-rate, 45,535 R-R and 69,851 gravity samples is not a thin night. Two known mechanisms produce exactly this, and they need different work: Fragmentation by gravity dropouts (#308). The in-bed spine fragments at every gravity gap over the tolerance, then every fragment under the 60-minute floor is dropped, so a real six-hour night can collapse to nothing. A rescue bridge exists but is gated on the night looking SPARSE, measured as gravity SPAN against heart-rate span rather than sample count. Fragmented to nothing on a DENSE night (#1937). The same collapse on a night whose gravity coverage is good, where that sparse gate therefore declines the rescue. A real capture had five runs, 298 minutes of detected sleep, every one about a minute short of the floor, and the night vanished. Both are survivable; which one you are in decides what changes. The one line that tells them apart You already have the right Test Centre profile on, Sleep and Rest, which is exactly what enables these traces, so this should already be in your log rather than needing a new capture. Please paste just the sparseBridge lines for one affected day: sparseBridge sparse=<true|false> fragmentedToNothing=<true|false> gapMin=90 runsBefore=<n> runsAfter=<n> plus any per-pair lines beside it, which each carry one of bridged, gapTooLong, hrOutOfBand, overlap or activeTooLong, and the [sleep] hr-only gate line if one is present. That is counts and tokens only: no timestamps, no sensor values, nothing identifying. Please do NOT attach your export here, and no need to post the raw streams. What each answer would mean: runsBefore=0: no sleep run was built at all, so the question moves upstream to stillness classification and the heart-rate baseline, not to the bridge. runsBefore of several with runsAfter the same, and a per-pair gapTooLong or hrOutOfBand: the rescue was attempted and refused, and the refusing rule is named. sparse=false fragmentedToNothing=false with several runs: the rescue was never enabled on a night that needed it, which is the #1937 shape one step further out. If you can paste the same lines for October 20 and October 23, that is more useful than three separate reports: identical trace shapes across all three mean one cause rather than three, and that is the difference between one change and an investigation per night. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>
4. ryanbr

   added a commit that references this issue on Oct 25, 2026

   feat(analytics): record the hour a flat 24-hour day window misplaces

   ...

   6d75039