Leap time handling

[dsweber2]

Checklist

Please:

• Make sure this PR is against "dev", not "main".
• Request a review from one of the current epipredict main reviewers:
  dajmcdon.
• Make sure to bump the version number in DESCRIPTION and NEWS.md.
  Always increment the patch version number (the third number), unless you are
  making a release PR from dev to main, in which case increment the minor
  version number (the second number).
• Describe changes made in NEWS.md, making sure breaking changes
  (backwards-incompatible changes to the documented interface) are noted.
  Collect the changes under the next release number (e.g. if you are on
  0.7.2, then write your changes under the 0.8 heading).
• Consider pinning the epiprocess version in the DESCRIPTION file if
  • You anticipate breaking changes in epiprocess soon
  • You want to co-develop features in epipredict and epiprocess

Change explanations for reviewer

So weeks and days both have to deal with inconsistent numbers of days. What this does:

1. separate out the "weird" day/week into a separate bin, labeled 999 and only use up to the "normal" number of days/weeks (so 365/52)
2. if the window goes over the boundary (so includes both week 52 and week 1, or both day 59 and day 60), then add in the data from
3. if the window is around the leap day/week, include the window days before and the window days after (so days 57, 58, 59, leap_day, 60, 61, 62)

Magic GitHub syntax to mark associated Issue(s) as resolved when this is merged into the default branch

• Resolves #{issue number}

[dajmcdon]

Some suggestions, but I think there's a logic error when rolling with the iter. (Probably was there before as well)

[dajmcdon]

Suggested change

	entries <- ((iter - window_size):(iter + window_size) %% modulus)
	entries <- (iter - window_size):(iter + window_size) %% modulus

Don't need the outer paren do we?

[dajmcdon]

Actually, I'm concerned this logic fails if given partial years. Same with keying on the iteration below. Suppose that I give you only data for January-March for 25 years (and ask for daily). Then max(iter)=91 so the leap branch will never happen. The same would be true if I removed the summer for every year and asked for epiweek climate. I think it needs to key on the .idx rather than iter.

The tests all presume you have every possible .idx covered and arranged.

[dsweber2]

Less than a full year of data is definitely a super pathological case. Switching it to matching .idx values rather than assuming the rows are right does seem to work though. I'm including a test in the next commit

[dajmcdon]

Is this resolved? (I don't think this is pathological at all. Giving flu seasons, August to April, every year for multiple years and cutting out the summer would break it.)

[dajmcdon]

do we need a

entries[entries == 0] <- 365

here?

[dsweber2]

Yes I suppose so, though it requires window_size = 60 to become relevant