Sfoglia il codice sorgente
Fix/stats inclusive range - replaces #621 (#629)
* Fix inclusive date counting in stats period calculations
## Problem
The stats model had a systematic off-by-one error in how it calculated
the number of days in an analysis period, and used `Date()` (now, today)
as the end boundary, including the current incomplete day in averages.
### Root causes
1. **Today was used as `endDate`** (`AggregatedStatsViewModel.updatePeriod`).
Today is a partial day and should never be included in averages.
2. **Exclusive date diff used as day count** (`StatsDataService.updateDateRange`).
`dateComponents([.day], from: start, to: end)` returns the number of
whole days between two instants, which excludes the end day. A range
of Apr 19–Apr 25 returned 6, not 7.
3. **Quick-select presets were off by one** (`DateRangePicker.setDateRange`).
Pressing "7d" subtracted 7 days from the start of yesterday, producing
an 8-day window (Apr 18–25) instead of a 7-day window (Apr 19–25).
4. **Day count label was exclusive** (`DateRangePicker.dayCount`).
The "(N days)" header label used the same exclusive diff, showing one
fewer day than the range actually covered.
5. **Bolus cutoff re-derived from `Date()`** (`SimpleStatsViewModel`).
The cutoff for filtering bolus dates was recalculated as
`Date() - requestedDays * 86400` instead of using `dataService.startDate`,
making it inconsistent with the resolved date range after today was
removed from the end boundary.
6. **Same re-derivation bug in `calculateActualDaysCovered`**.
The helper also anchored its own cutoff to `Date()` rather than
`dataService.startDate`.
7. **Carbs denominator used days-with-data, not period length**
(`SimpleStatsViewModel`). `avgCarbs` divided total carbs by
`dailyCarbs.count` (number of days that had at least one carb entry),
which inflates the average whenever the user had carb-free days in the
period. The band-aid `max(dailyCarbs.count, 1)` was a symptom of this.
## Fix
**`AggregatedStatsViewModel.updatePeriod()`**
- `endDate` = 23:59:59 of yesterday (last complete day), computed via
`startOfDay(for: Date()) - 1 second` using the display calendar.
- `startDate` = midnight of `endDay - (days - 1)` so that a "7d" period
covers exactly 7 calendar days inclusive (e.g. Apr 19–Apr 25).
**`StatsDataService.updateDateRange()`**
- `daysToAnalyze` = `daysBetween + 1`, where `daysBetween` is the
exclusive `dateComponents` diff between the start-of-day of each
boundary. Computing on day-start timestamps avoids DST-induced
sub-day remainders from inflating the count.
**`DateRangePicker.setDateRange()`**
- Start offset changed from `-(days)` to `-(days - 1)` so quick-select
presets (7d, 14d, 30d, 90d) produce inclusive ranges.
**`DateRangePicker.dayCount`**
- Day count = exclusive diff between start-of-day boundaries + 1,
ensuring the header label matches the actual number of days covered.
**`SimpleStatsViewModel` — bolus cutoff**
- `cutoffTime` now reads `dataService.startDate.timeIntervalSince1970`
directly. This is consistent with the resolved period and avoids
re-deriving a different value from the current clock.
**`SimpleStatsViewModel` — carbs denominator**
- Denominator changed from `dailyCarbs.count` to `dataService.daysToAnalyze`
so that carb-free days are included in the average (total carbs spread
over the full period, not just days with entries).
**`SimpleStatsViewModel.calculateActualDaysCovered()`**
- Cutoff changed from `Date() - requestedDays * 86400` to
`dataService.startDate.timeIntervalSince1970` for the same reason as
the bolus fix above.
## Time zone behaviour
All day-boundary arithmetic uses `dateTimeUtils.displayCalendar()`, which
applies the user's configured graph time zone or the device's current time
zone. This means:
- DST transitions are handled correctly: `startOfDay(for:)` and
`date(byAdding: .day)` use calendar days, not fixed 86400-second
intervals, so 23-hour and 25-hour DST days do not shift boundaries.
- Travel (device time zone change) causes the analysis window to be
recomputed relative to the new local midnight on the next load, which
is the expected behaviour.
- Users with a fixed graph time zone are fully insulated from travel:
all boundaries stay anchored to the configured zone.
* Fix initial stats view opening with exclusive 7-day offset
AggregatedStatsView.init() was hardcoding the initial @State dates with
value: -7 from endDayStart, producing an 8-day window (Apr 18–Apr 25)
instead of the intended 7-day inclusive window (Apr 19–Apr 25).
The previous commit fixed setDateRange() and updatePeriod() but missed
this init(), which bypasses both and seeds the @State directly.
* Extract N-day range rule into StatsDateRange
The "last complete N-day period" calculation was duplicated in
AggregatedStatsView, AggregatedStatsViewModel, and DateRangePicker.
Centralise it in a new StatsDateRange.lastComplete(days:) utility and
replace all three inline copies.
https://claude.ai/code/session_016oKb1eyTs8TfMq7drfmcg3
---------
Co-authored-by: Claude <noreply@anthropic.com>