fix: correct travel segment placement for next-day departures

Travel segments appeared one day too late on featured/suggested trips
when stops had next-morning departures. The placement formula double-
counted by using fromDayNum+1 as both minDay and defaultDay, then the
invalid-range fallback used minDay (the overshooting value) instead of
the arrival day. Also replaced TripDetailView's inline copy of the
placement logic with TravelPlacement.computeTravelByDay() so the UI
uses the same tested algorithm.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
Trey t
2026-02-11 09:53:25 -06:00
parent d63d311cab
commit 633f7d883f
3 changed files with 144 additions and 37 deletions

View File

@@ -45,7 +45,9 @@ enum TravelPlacement {
minDay = max(fromDayNum + 1, 1)
maxDay = min(toDayNum, tripDays.count)
defaultDay = minDay
// Cap default at the arrival day to prevent overshoot when
// departure is already the next morning (fromDayNum+1 > toDayNum).
defaultDay = min(fromDayNum + 1, toDayNum)
} else {
minDay = 1
maxDay = tripDays.count
@@ -56,7 +58,9 @@ enum TravelPlacement {
if minDay <= maxDay {
clampedDefault = max(minDay, min(defaultDay, maxDay))
} else {
clampedDefault = minDay
// Invalid range (departure day is at or past arrival day).
// Fall back to arrival day, clamped within trip bounds.
clampedDefault = max(1, min(defaultDay, tripDays.count))
}
travelByDay[clampedDefault] = segment