Fix off-by-one preventing download of today's data (#264)

[letz]

The download date range always stopped at yesterday, so checking today's sleep or stats required waiting until the next day.

range(0, (today - date).days) excluded today because both range() and timedelta.days are end-exclusive. Adding + 1 to the three date-delta calculations makes the date range inclusive of today.

[letz]

@tcgoetz I just saw #316 (comment)

Can you explain it better? If I'm not missing something, the download already handles overlap downloads from 3 days earlier and the database does the upsert. it shouldn't have duplicated data

[tcgoetz]

I can't give a detailed explanation because its from long ago. I know there was an issue early on and I've never done anything to fix it, so I assume its still there.

One thought is that when downloading Garmin Connect data to JSON files, it checks if they exist and doesn't bother downloading if they already exist. We want this behavior for all days except partially days. It saves a lot of downloading and avoids load on the GC API. Anything that was already downloaded for the current day would be partial, but how do you know that you downloaded partial data was downloaded some day in the past? Not downloading partial days at all was an easy solution.

So, how do you determine when already downloaded JSON files represent partial data?

This will also require a lot of testing across a bunch of data types.

[letz]

Thanks for the context.

So, how do you determine when already downloaded JSON files represent partial data?

A complete daily file can only have been written after the day it represents ended:

• modified file time > end-of-represented-day → complete, skip
• modified file time ≤ end-of-represented-day → partial, re-download

Do you think that would work?

The existing download_days_overlap = 3 already handles the common case — if a user syncs
daily, partial files for today get re-downloaded the next day (within the 3-day window) and
there's no issue. This proposal doesn't change any of that behavior.

The only gap it closes is when a user stops syncing for more than 3 days. In that case, a
partial file from day 1 falls outside the 3-day overwrite window on day 5+ and stays partial
permanently. The mtime check catches it on whichever sync comes next, no matter the gap.

[tcgoetz]

That could work.