Reset groups finished sessions by their local end date. An overnight interval that starts on Monday and finishes on Tuesday appears with Tuesday’s completed sessions. This is the first thing to check when a record seems to be on the wrong day.
Start date and reporting date differ
Consider a session from Monday 8 pm to Tuesday 10 am. It starts Monday, lasts 14 hours and ends Tuesday. Those statements are consistent.
A history grouped by starts would place it on Monday; Reset’s end-date grouping places it on Tuesday. The difference is an organisational rule, not an extra day added to the duration.
Check the selected period
The seven-day, 30-day and all-time views include different sets of finished sessions. A record near the boundary can appear or disappear when you change the filter.
An active session has not finished yet, so it is not part of the finished-session totals. Check the active timer before assuming an entry is missing.
Account for local time-zone changes
Session timestamps can display as different local clock times after travel. An endpoint near midnight can even fall on a different local date in the new zone.
Read tracking across time zones before editing a travel record. Changing a correct timestamp to match an old clock label can introduce an error.
Inspect the actual entry before correcting it
Open the session and check both endpoints. If the dates really are wrong, use the editor to fix them. If the dates are right and only the grouping differs from your expectation, leave the record intact.
For chart questions, remember that longer views use grouped bars. A bar label is not always the date of a single session. The chart-reading guide explains that distinction.
A useful history has consistent rules. Understanding those rules is more reliable than moving entries around until the display resembles a different calendar convention.