Handle summer time jumps in event recurrences

[phil-davis]

Issue #648

1st commit is the test code added by @schreven in PR #647

2nd commit is my first code that makes those test cases pass. It only touches the case of events that recur at an interval of days.

• added more test cases for weekly, monthly and yearly recurring events, that are engineered so that some event recurrence fall in the 0200 to 0300 summer time start on the exact day that summer time does start.
• adjusted code to make those pass (similar to what I did for the daily case)
• refactored to avoid the repeated code pattern
• added tests and adjusted code for nextHourly

Thanks to @gharlan and @schreven for input, code suggestions etc.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 98.78%. Comparing base (72a1fe9) to head (2b32d40).
Report is 1 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff            @@
##             master     #653   +/-   ##
=========================================
  Coverage     98.78%   98.78%           
- Complexity     1869     1872    +3     
=========================================
  Files            71       71           
  Lines          5254     5265   +11     
=========================================
+ Hits           5190     5201   +11     
  Misses           64       64           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[schreven]

It looks better than my attempt. In the end wasn't it possible to store the "unaltered" datetime as mentioned here?

One idea would be to have a new object that extends DateTime and overrides DateTime::format() to not alter the datetime on leaps. It would then be used in the main loop, and transformed to a traditional datetime when returned.

[phil-davis]

In the end wasn't it possible to store the "unaltered" datetime as mentioned

The "unaltered" time, for example "0230" is not a valid time on the date when summer time starts. So the DateTime object cannot store that date-time combination. I also thought about remembering the original required time-of-day in a separate variable. But in the end I could just detect if the time-jump happened, and remember that.

There are other possible edge-cases, but they don't really happen. For example, if 2 recurrences in a row fall on the summer time start date, then reversing the hour-jump would have to be delayed. But in real-life, summer time usually starts on a Sunday morning. For a yearly event, the recurrence in the next year is always 1 or 2 days later in the week, so there can't be 2 Sunday's in a row for a yearly event. But someone could design an event that happens at 0230 every 52nd Sunday - and that could fall on the summer time start date for a few years in a row!

[schreven]

Nitpick: We can re-use the function right?

Suggested change

	$tempDate = $tempDate->modify('+ '.($this->interval * $increase).' months '.$this->startDate->format('H:i:s'));
	$tempDate = $tempDate->advanceTheDate('+ '.($this->interval * $increase).' months ');

[schreven]

Question: Should we not handle the execution going to the rest of the function as well? I would well see a line at the very end to set the time straight:

$this->startDate->modify($this->startDate->format('H:i:s'));

[schreven]

Nitpick:
With the comments it's adding a lot of lines to this function. Perhaps we can move the new code to a private function "AdjustForTimeJumps"