0

Please consider the following code

String pattern = "*/17 * * * *";
Date d = new Date();
for (int i = 0; i < 10; i++) {
      System.out.println("Start: " + d + ", " + (d = new Predictor(pattern, d).nextMatchingDate()));
}

This outputs the following sample (I put the times I didn't expect between brackets):

Start: Tue Jun 11 12:54:48 GMT+02:00 2013, Tue Jun 11 (13:00:00) GMT+02:00 2013
Start: Tue Jun 11 13:00:00 GMT+02:00 2013, Tue Jun 11 13:17:00 GMT+02:00 2013
Start: Tue Jun 11 13:17:00 GMT+02:00 2013, Tue Jun 11 13:34:00 GMT+02:00 2013
Start: Tue Jun 11 13:34:00 GMT+02:00 2013, Tue Jun 11 13:51:00 GMT+02:00 2013
Start: Tue Jun 11 13:51:00 GMT+02:00 2013, Tue Jun 11 (14:00:00) GMT+02:00 2013
Start: Tue Jun 11 14:00:00 GMT+02:00 2013, Tue Jun 11 14:17:00 GMT+02:00 2013
Start: Tue Jun 11 14:17:00 GMT+02:00 2013, Tue Jun 11 14:34:00 GMT+02:00 2013
Start: Tue Jun 11 14:34:00 GMT+02:00 2013, Tue Jun 11 14:51:00 GMT+02:00 2013
Start: Tue Jun 11 14:51:00 GMT+02:00 2013, Tue Jun 11 (15:00:00) GMT+02:00 2013
Start: Tue Jun 11 15:00:00 GMT+02:00 2013, Tue Jun 11 15:17:00 GMT+02:00 2013

Although the pattern is configured to match minutes divisible by 17, if that's a correct way to describe it, the predictor considers a precise hour (13:00, 14:00, 15:00..etc) a valid next-matching-date !

My questions are:

  • Is this behavior valid ? If yes, then why is it valid ?
  • How can I prevent this behavior ? I mean how can I prevent the predictor from considering a precise hour as a matching time if the time field (i.e. minutes, hours, days, week day) isn't divisible by it's maximum value (i.e. 60, 24, 30 or 31, 7) ?
  • Is this actually the case with unix cron scheduling ?

Thank you.

Muhammad Gelbana
  • 3,890
  • 3
  • 43
  • 81

1 Answers1

0

In this context 0 and * are interchangable. So it will run on the hour and then at 17 minute intervals during the hour.

To start at 17 minutes past the hour and then at that duration try this pattern: 17-59/17 * * * *

darrenmc
  • 1,721
  • 1
  • 19
  • 29
  • Is that the case for the Unix cron scheduler ? Thanks for the pattern but all the next-matching times are at the minute 17 only (i.e. 18:17, 19:17, 20:17..etc) – Muhammad Gelbana Jun 11 '13 at 16:10
  • Yes that is for unix cron. I must admit that I have not used cron4j but the quartz schedluer cron bean instead. – darrenmc Jun 11 '13 at 16:17
  • You could try "17-59/17 * * * *" as that range syntax may be supported – darrenmc Jun 11 '13 at 16:18
  • I was hoping for a more generic method. Something that I don't need to process using code so it would just work. – Muhammad Gelbana Jun 11 '13 at 16:30
  • According to the cron4j documentation it does support a range. I have updated my answer. – darrenmc Jun 13 '13 at 10:33
  • I appreciate your help. But I guess that so far, the answer is that this is just how Cron4j works. If I need to avoid hitting the 00 minutes if the minutes specified isn't divisible by 60, then I'll have to perform extra processing and do as you mentioned (17-59, 7-23 for */7 hours as not to hit midnight, etc). I need to perform this as easily and reliably as possible to avoid major code re-factoring. I was hoping that cron scheduling patterns support this somehow. – Muhammad Gelbana Jun 13 '13 at 12:16
  • I'm not sure I understand you correctly. That is the cron pattern. But yes you would need to determine that for minutes the range is up to 59, and hours it is 23 etc if you are generating the pattern programmatically. – darrenmc Jun 13 '13 at 12:46
  • I'm basically asking for a generic/standard way to solve the problem. */17 is just an example. I need to be able to solve */5 and */17 cases in a standard way (If there is any) so I don't have to modify my code and of course avoid new bugs/issues in the future. I'm constructing the pattern from user input fields and it's a very complicated process. – Muhammad Gelbana Jun 13 '13 at 14:32
  • Have you seen http://www.cronmaker.com/ Internally it uses the quartz library to construct the cron expression from user input. You may be able to do something similar. – darrenmc Jun 13 '13 at 16:04