"Impossible CRON expression" for expressions that occur on DST change over

[AllenJB]

$expression = "0 1 * * 0";
$cronex = CronExpression::factory($expression);
$tz = new \DateTimeZone("Europe/London");
$dtCurrent = \DateTimeImmutable::createFromFormat("!Y-m-d H:i:s", "2021-03-28 14:55:03", $tz);
$result = $cronex->getPreviousRunDate($dtCurrent, 0, true, $tz->getName());

This case returns an impossible cron expression exception, despite the cron expression being valid and possible.

(For reference Europe/London switched from UTC+0 to UTC+1 at 2021-03-28 01:00:00 UTC )

Performing getNextRunDate using the day before appears to work (may not be what the user might expect, but it's "valid"):

$dtCurrent = \DateTimeImmutable::createFromFormat("!Y-m-d H:i:s", "2021-03-27 14:55:03", $tz);
$result = $cronex->getNextRunDate($dtCurrent, 0, true, $tz->getName());

Returns 4th April

I tested using v3.1.0

[AllenJB]

Just a side note on a workaround for this that I've implemented (I only have to deal with a specific subset of expressions that express a particular time on a particular weekday - month and day of month are always '*' and no '/', ',' or other "special cases" in any given job specification):

If a forward offset transition occurred this week, and the day of week and hour value is the same as the transition, add one hour.

You can use DateTimeZone->getTransitions($timestampLastWeek, $timestampNow) to determine if and when a transition occurred in the past week.

[AllenJB]

I think this bug may be sensitive to the PHP version being used. 7.4.3 on Windows 10 appeared to not trigger the bug, but 7.4.19 from remi repo on CentOS 7.9 did. After upgrading to PHP 8.0 on Windows 10, the bug now also triggers there.

(There have been no recent changes to the Europe/London timezone as far as I am aware - it doesn't vary its DST changeover dates like some zones do, so I doubt it's a change in timezone definitions)

Scanning the NEWS file in php-src 7.4 branch, the date extension bug fixes in 7.4.5 look like the best candidates for a related change.

Edit: After further testing, I'm now sure the fix for https://bugs.php.net/bug.php?id=79396 broke this library

I set a watch on the datetime value as it's manipulated by the HoursField when attempting to run the above error triggering code.

The result is that the library keeps trying to setTime(1, 59) on the value 2021-03-28T02:59:00+01:00 - it will do this eternally because doing this results in the same value due to the DST forward jump.

---

I have a draft of a fix for this at https://github.com/AllenJB/cron-expression/tree/dst_change
I'm not quite ready to PR it yet - want to do some more testing tomorrow (for nth != 0, multiple run dates and some non-round-hour-jump timezones) but so far it's passing all tests.

---

Update: I discovered more fun bugs / unexpected behavior in PHP's DateTime handling. This is taking longer than I hoped. I am persevering tho.