Change function parseRange to this:
Its impossible pass string $range with array.

private function parseRange(array &$register, int $index, string $range, int $stepping): void
    {
        if ($range === '*') {
            $rangeArr = [self::VALUE_BOUNDARIES[$index]['min'], self::VALUE_BOUNDARIES[$index]['max']];
        } else {
            $rangeArr = explode('-', $range);
        }

        $this->validateRange($rangeArr, $index);
        $this->fillRange($register, $index, $rangeArr, $stepping);
    }

when i want 1,2 * * * *
1 is right,
2 not getNext

$t = null;

for ($i = 0; $i < 20; $i++) {
    $c = new \Cron('0 1 * * *');
    echo date('Y-m-d H:i:s', $t = $c->getNext($t)) . "<br />";
}

Expected:

2017-06-04 01:00:00
2017-06-05 01:00:00
...

Actual:

2017-06-04 01:00:00
2017-06-04 01:00:00
...

Hey,

I discovered a bug in this package. If you use 59 23 31 6 * (the date is not valid) expression then the getNext ends in infinity loop.

$c = new \Cron('0 3 * * *');
echo $c->getNext();

Executed at 2022-03-30 01:55:01
Expected:

2022-03-30 03:00:00

Actual:

2022-03-30 05:00:00

if Cron('1 0 * * *'), getNext() will return next day 00:00:00 ? why not 00:01:00 ???

The package is missing a namespace and could possibly use a more on-point name (like CronExpression or something).
It's a small issue for a great tool, thanks! Saved me a bunch of time.

I've run into a strange problem while calculating the next execution date. I have a cron configured for January 1st at 00:00. It was working well before, saying that next execution would be on 2023-01-01 00:00. Today, however, it says 2024-01-01 00:00.

Using the existing test for the class I was able to pinpoint the breaking point. The calculation for next year works well until December 1st at 00:00:59. Past this time, the class will calculate the next execution skipping one year.

To reproduce, you can add this to getNextProvider on CronExpressionTest.php:

['0 0 1 1 *', 1669849200, 1672527600], // on 2022-12-01 00:00:00, next execution at 2023-01-01 00:00:00

This one works well. 1669849200 is December 1st, 2022 at 00:00. 1672527600 is January 1st, 2023 at 00:00, as expected.

['0 0 1 1 *', 1669849260, 1672527600], // on 2022-12-01 00:01:00, next execution at 2024-01-01 00:00:00

This one fails. 1669849260 is one minute later, December 1st, 2022 at 00:01. This results in 1704063600, which corresponds to January 1st, 2024 at 00:00.

Hi there,

I found a bug with cron: 0-30/2 02,06-19 5-30/5 1-11 1-2,4-5.

In fact this is a valid cron, but the ìsValidî method sends false.

I think I have found the origin of this error:

Here we are comparing 2 and 02.

But 02 = 2 is an integer.

Similar #9

$c = new \Cron('0 3 * * *', new \DateTimeZone('Europe/Paris'));
echo $c->getNext();

When run at 1649202901 //2022-04-06 01:55:01

Expected:

1649206800 //2022-04-06 03:00:00

Actual:

1649206800 //2022-04-06 03:00:00 OK

When run at 1649203201 //2022-04-06 02:00:01

Expected:

1649206800 //2022-04-06 03:00:00

Actual:

1649293200 //2022-04-07 03:00:00 ERROR

Thank you for the v3.0.1. It works better.
But I think that I found 2 new errors.

$tests = [
  [
    "expression" => '0 10 * * *',
    "timezone" => 'Europe/Paris',
    "now" => "2022-04-11T10:00:00+02:00", //1649664000
    "expected" => "2022-04-12T10:00:00+02:00" //1649750400
  ],
  [
    "expression" => '0 10 * * *',
    "timezone" => 'Europe/Paris',
    "now" => "2022-04-11T10:02:00+02:00", //1649664120
    "expected" => "2022-04-12T10:00:00+02:00" //1649750400
  ],
];

foreach($tests as $test){
  $expr = new CronExpression($test['expression'], new DateTimeZone($timezone));
  $now = strtotime($test['now']);
  $test['getNext'] = $expr->getNext($now);
  $test['getNext_c'] = date('c', $test['getNext']);
  $test['result'] = ($test['getNext_c']==$test['expected']?"ok":"** ERROR **");
  print_r($test);
}

Output:

Array
(
    [expression] => 0 10 * * *
    [timezone] => Europe/Paris
    [now] => 2022-04-11T10:00:00+02:00
    [expected] => 2022-04-12T10:00:00+02:00
    [getNext] => 1649714400
    [getNext_c] => 2022-04-12T00:00:00+02:00
    [result] => ** ERROR **
)
Array
(
    [expression] => 0 10 * * *
    [timezone] => Europe/Paris
    [now] => 2022-04-11T10:02:00+02:00
    [expected] => 2022-04-12T10:00:00+02:00
    [getNext] => 1649714400
    [getNext_c] => 2022-04-12T00:00:00+02:00
    [result] => ** ERROR **
)

See PR

$c = new \Cron('0 3 * * *');
echo $c->getNext();

When run at 2022-03-25 01:55:01

Expected:

2022-03-25 03:00:00
...

Actual:

2022-03-25 03:00:00 OK
...

When run at 2022-03-25 02:00:01

Expected:

2022-03-25 03:00:00
...

Actual:

2022-03-26 03:00:00 ERROR
...

Thank you for the v3.0.0. I don't know if it is linked to #9 and #11 but I still encounter a similar issue :

$c = new \Cron('0 3 * * *', new \DateTimeZone('Europe/Paris'));
echo $c->getNext();

When run at 1649548801 //2022-04-10 02:00:01

Expected:

1649552400 //2022-04-10 03:00:00

Actual:

1649552400 //2022-04-10 03:00:00 OK

When run at 1649549102 //2022-04-10 02:05:02

Expected:

1649552400 //2022-04-10 03:00:00

Actual:

1649638800 //2022-04-11 03:00:00 ERROR

Hello,
Sorry, I am not a native English speaker.
I read the repo's source code. This is what I need.
But this code can use regular expression to check cron rule more faster.
This is my regular expression: ^((\d+|(\d+-\d+|\*)(/\d+)?)(,(\d+|(\d+-\d+|\*)(/\d+)?))*|[a-zA-Z]+)$.

Please update composer.json to support PHP 8.3

I have tested poliander/cron on latest PHP 8.3.0-dev (Homebrew) and all tests seem to run through fine:

$ php -v
PHP 8.3.0-dev (cli) (built: Oct 27 2023 15:45:44) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.3.0-dev, Copyright (c) Zend Technologies
    with Zend OPcache v8.3.0-dev, Copyright (c), by Zend Technologies

$ ./vendor/bin/phpunit 
PHPUnit 9.6.13 by Sebastian Bergmann and contributors.

...............................................................  63 / 120 ( 52%)
.........................................................       120 / 120 (100%)

Time: 00:00.008, Memory: 6.00 MB

OK (120 tests, 224 assertions)