Thanks for library. But it gives wrong result for * rules (0 0 1 */3 * should run 1,4,7,10 month, in fact it runs on 3,6,9,12).

Please see this discussion for more info.

In PHP 5.5 with the builtin Opcache enabled for the CLI using the CronExpression causes memory leaks.

opcache.enable_cli = 1

Execute the following script on the command line:

use Cron\CronExpression;

$expression = CronExpression::factory('25 0 1 * *');

while (true) {
    $expression->isDue();

    usleep(100000);
}

The used memory (RSS) will increase rapidly and PHP will eventually throw a fatal error.

Please note that when changing the expression to * * * * * this issue does not occur.

It may very well be an issue with the Opcache, however I haven't been able to pinpoint exactly what is happening here.

Tested on CentOS 6.4 and Mac OS X 10.9.2 with PHP 5.5.10 and PHP 5.5.11

In Laravel's scheduler component, we allow the user to specify a Timezone to evaluate the Cron against. However, cron-expression appears to always overwrite the timezone to the current application timezone, allowing no custom timezone to be set.

Is there any way this can be resolved?

Since this repo no longer sees any development (since it has continued in a different repo), it makes sense to mark the accompanying package as abandoned on packagist.

Hello.

Just had a cron run this weekend and my script failed. Looks like it's having trouble finding the previous run date on the day of March 17, 2013. The cron expression being used is weekly.

Thanks, Kyle

this cron 13 14 3 2 3 throws the impossible cron exception

if i test it ( http://cron.schlitt.info/index.php?cron=13+14+3+2+3&iterations=10&test=Test ), i should get:

2016-02-03 14:13:00
2016-02-10 14:13:00
2016-02-17 14:13:00
2016-02-24 14:13:00
2017-02-01 14:13:00
2017-02-03 14:13:00
2017-02-08 14:13:00
2017-02-15 14:13:00
2017-02-22 14:13:00
2018-02-03 14:13:00
...

I have noticed that I get a "Impossible CronExpression" error any time I have a cron expression that has expired or is in the past.

A little background on how we are using cron-expression. We have maintenance schedules which are scheduled via cron expressions, which makes perfect sense as many are recurring on a set schedule. However, there are times when the maintenance schedule is just for a couple of hours early in the morning and it is a one time thing. That is when we start running into issues.

Example: If today's date/time is 1/29/2015 12:00 and we have a cron expression for a maintenance schedule of "* 1-4 29 1 * 2015" we will get a "Impossible CronExpression" error thrown when checking it through the IsDue() method. Which I assume is because that expression represents a time in the past.

For entering a new cronExpression for a time in the past, an error or warning like this makes sense, but not for a cronExpression that, when entered, was/is valid and as time goes it becomes a time in the past. That should not error out I would think. Any ideas as to why this is happening? And how one would go about fixing it?

Any help on this issue would be most appreciated.

Thanks,

• Barrett-

Love this code...thank you...it has solved and consolidated many things for me. The one "problem" I had was that running my "cron" every minute was going to be too much. So, I looked into running it every 10 minutes and having the code detect what should have run within those 10 minutes.

I updated the isDue function to allow an interval of minutes to be checked so that you would not need to run this function "once per minute" and could pick up events within the designated interval. also added tests to demonstrate usage and check the boundaries.

A couple of public-facing APIs are prepared to accept DateTime instances, but not DateTimeImmutable. This PR updates the code so that it also accepts DateTimeImmutable.

I tried to make the minimum possible volume of modifications, which means that the result doesn't read as nicely as fresh code written with PHP 5.5 in mind. I'm willing to rewrite more if that is required.

Hi , I am from India and my Timezone is UTC +5:30

now the problem that arises to me is that assume the cron entry is "25 0 * * *"

the time now say is 2014-05-13 17:19:00 so the next run time is 2014-05-14 00:25:00

in first loop obviously 0 doesn't match with 17 so the 17 is incremented .. but here is the issue .. as we are converting to UTC and back .. after increment the time changes to .2014-05-13 17:30:00 notice that the minute is now 30 which is greater than 25.

after the increments are as follows 2014-05-13 17:30:00 2014-05-13 18:30:00 2014-05-13 19:30:00 2014-05-13 20:30:00 2014-05-13 21:30:00 2014-05-13 22:30:00 2014-05-13 23:30:00 2014-05-14 00:30:00

And here the cron expression has been completely missed out and the system gets into an infinite loop

for the time being I have removed the covert to UTC and back feature as we don't need to deal with DST

Hi there, this looks awesome and I'm considering using it for piwik but it looks like the last release is a year old (51 commits behind master).

Is that possible to tag a new release?

If it helps getting there faster, here is the changelog:

• Avoid infinity loop & division by zero #67
• Fix getRunDate() shouldn't modify currentTime parameter #57
• Missing anchors in regexp #63
• Avoid annotation parsing by Doctrine #62
• Optimization #52
• Fixed #20 Weekday-Hash for Saturday and Sunday doesn't seem to work #53
• Different timezone support #48
• Fixed regexp for day of week #49
• Set $currentTime as 'now' #36

I kept only the changes meaningful for end-users (e.g. not changes about tests or docs).

dragonmantank\cron-expression (v3.1.0)

$expr = '0 0 1/2 * *'; $cron = \Cron\CronExpression::factory($expr); echo $cron->getNextRunDate()->format('Y-m-d H:i:s');

InvalidArgumentException in C:\vendor\dragonmantank\cron-expression\src\Cron\CronExpression.phpat line 158 Invalid CRON field value 1/2 at position 2

mtdowling/cron-expression (v. 1.2.3) execute this code correct (w/o Exception)

If the result of getPreviousRunDate happens to be within the "missing" hour during DST change, an "Impossible CRON expression" error is thrown.

I'm getting an 'impossible cron expression' error which seems to be a combination of day of the week, the Sydney timezone, and the particular 'current date' of 3/27.

$dateTime = Cron\CronExpression::factory('0 0 * * 1')->getNextRunDate(Carbon\Carbon::create(2017, 3, 27, 0, 0, 0, 'UTC')->timezone('Australia/Sydney'));

If both fields are restricted (for day of month and day of week) a cron should match for either case, as per the cron man:

 Note: The day of a command's execution can be specified by two fields --
 day of month, and day of week.  If both fields are restricted (ie, are
 not *), the command will be run when either field matches the current
 time.  For example, ``30 4 1,15 * 5'' would cause a command to be run at
 4:30 am on the 1st and 15th of each month, plus every Friday.

However, in a test with the following expression:

0 16 4 * fri *

The expected behavior is every Friday OR every month on the 4th.

However, when running this, it matches if it is a Friday AND it is the forth: here is sample output:

Next: Fri, 04 Nov 2016 16:00:00 +0000 Last: Fri, 04 Mar 2016 16:00:00 +0000

Great library otherwise.

I didn't notice anything in the source handling daylight savings time. Cron's consideration for this is that any time changes less than 3 hours should be considered daylight savings time.

Not handling this would mean that hour-based runs could run more than they are suppose to. For example if something were scheduled for 2AM it would run twice when rolling back.

See: https://www.pantz.org/software/cron/croninfo.html