TYPO3 Core

code example for this bug:

$cronCmd = new tx_scheduler_CronCmd('31 2 * * 1', mktime(10,0,0,12,28,2010));
$cronCmd->calculateNextValue(0);
$tstamp = $cronCmd->getTstamp();

echo strftime('%Y-%m-%d', $tstamp);

-> outputs 2011-01-10 (should output 2011-01-03)

Hi,
can confirm, calculateNextValue seems to be the problem, indeed.

In case no next_value can be found for the current level, the second 'for' loop resets the higher levels until a level is reached where a valid next value (aka increased_value) is found.

If the month level is reached and no increased value ist found (as in the given example), the month value will be set to start value, the valid values for day level will be recalculetd, but no new start day value will be set (happening in the else branch of the unpatched code).

In order to not repeat to much code I didn't copy the setting of valid day start value into the else branch but rather dropped the whole check there and changes the if condition to recalculate day level if the value on year level has been increased.

(see patch attached)

The whole method using recursion and two loops to traverse the date levels is pretty hard to read and understand (at least for me ;-)). Perhaps it schould be rewritten and simplefied some day?

regards, Tobias

Committed v3 to 4.3 in revision 9826
Committed v3 to 4.4 in revision 9827, with the proposed unit tests.