Scheduling a trigger in the past runs the schedule now.

[Daniel Gabriel]

Hi,

I'm not sure if I missed something in the tutorial, but I'm observing behavior that seems strange to me. I create a cron trigger with the following expression:

"0 5 0 * * ? *". The start date and time of the trigger is yesterday at 12:05 AM. The trigger runs as soon as I add it to the scheduler, while I would expect it to run tomorrow at 12:05 AM.

The misfire instruction is default (which should be SmartPolicy for cron triggers, interpreted as FireOnceNow), yet in my IStatefulJob implementation the JobExecutionContext.Recovering flag is set to false.

What do I need to change for the trigger to fire on schedule, instead of immediately? The misfire instruction has to stay as FireOnceNow because there is additional logic happening in the job implementation for missed jobs.

Thanks,

-Daniel

[Daniel Gabriel]

Some additional info:

This is what I get from the JobExecutionContext in my job implementation for a trigger scheduled to start today at 12:05 AM (the trigger was added to the scheduler around 16:20 AM GMT):

context.ScheduledFireTimeUtc: Thu, 16 Dec 2010 16:20:22 GMT

context.FireTimeUtc: Thu, 16 Dec 2010 16:20:22 GMT

With the cron expression from above, how can this be the correct scheduled time?

[Daniel Gabriel]

Anyone? Marko? Does this sound like a bug in CronTrigger?

[Daniel Gabriel]

I'm still unable to find a solution to this problem. Am I the only one
who expects the CronTrigger to ONLY fire on a schedule that satisfies
the cron string?

On Dec 17 2010, 5:25 pm, Daniel Gabriel <daniel.e.gabr...@gmail.com>
wrote:

[RambleCampbell]

Daniel,

I'm pretty new to Quartz.NET myself, but two things come to mind:

1) If you want to skip the "missed" trigger, that is, the one that
occurred today at 12:05am, and wait for the next fire time, your
misfire instruction should be "DoNothing" -- that'll cause the trigger
to skip the previous trigger and wait for the next.

2) Make sure the startTimeUtc value you save has been adjusted for
your timezone. I learned this the hard way (and by bugging the crap
out of Marko until he could explain it to my dim brain). For example,
if you're in Central Time Zone (like me), and you want the trigger to
fire at 12:05AM CST, the start time will be 06:05:00AM GMT. The
scheduler runs everything in GMT, so 06:05:00AM GMT = 12:05:00 CST.
Make sense?

Hope that helps,
Landon

[Daniel Gabriel]

Thanks Landon!

1) Trouble is, Quartz doesn't think this schedule is "missed", it
thinks it's running as scheduled. My testing tells me the problem is
in the CronExpression class somewhere, as it doesn't fully support
setting a Timezone. This leads to miscalculated first runs where
CronExpression thinks that you are scheduling something earlier today
and makes the first run now.

2) Unfortunately, for CronTriggers just manually adjusting the time
won't work. What if you specify a schedule to run at 12:30am on
Wednesdays in GMT? In this case, once you adjust for your local
timezone (say, Eastern Standard Time, which is -5 hours from GMT), you
will get a schedule that runs at 7:30pm on Wednesday. But the correct
schedule would be to run at 7:30pm on Tuesday, because you moved 5
hours back and into the previous day.

Did Marko explain anything about the cron schedules?

Thanks again for your help!
-Daniel



On Jan 20, 10:41 pm, RambleCampbell <campbelllan...@hotmail.com>
wrote:

[RambleCampbell]

Daniel,

Did you ever get your CronTrigger issue resolved? Like I said, I'm
pretty new to Quartz myself, but I feel fairly certain that your
problems are coming from a combination of timezone and misfire
instruction configuration. Did you set the misfire instruction to
"DoNothing" on your CronTrigger? Regardless of other issues, if you
want to ignore "missed" fire times when you start the service, that
should be your setting.

Regarding the rest: as best as I can tell, CronTriggers are fairly
self-contained and, oddly enough, are timezone aware. If you're using
a database for your jobstore, look at the cron trigger table, and
you'll see that it has a timezone field! I haven't asked these guys,
but this must be one place where Quartz does use the local machine's
timezone automatically when creating objects, which is a little
confusing since everything else Quartz does is in GMT. However, before
I muddy the waters, let me just say: nof this should really matter. If
the CronExpression string is correct, forget about that part for now
and just trust it. The real issue has to do with your StartTimeUtc
field. What date are you using for that field? Is it coming from a GUI
by any chance? If so, you could be having the same problem I was,
which is that the GUI was already using universal time without any
awareness of timezone, so when I set StartTimeUtc =
myDate.ToUniversalTime, it caused a double-conversion, if you will,
and was totally screwing up the start time. So where is your
StartTimeUtc coming from? If you're simply creating a new DateTime on
a machine that is running in your timezone, make sure you do the
following:

DateTime myDateOnMyMachineWithTimezoneSetToEastern = new DateTime();
trigger.StartTimeUtc =
myDateOnMyMachineWithTimezoneSetToEastern.ToUniversalTime();

If you're using a GUI (or some other class) that sends you the start
date, you might want to check the "Kind" property on the DateTime
object and see what it is. What I finally realized was that my GUI had
a timezone-offset setting that did the conversion for me to universal
time! So, when I created the trigger, I didn't have to call
ToUniversalTime, because the GUI had already done it with the correct
timezone offset.

Does any of this make sense? Like I said, if your CronExpression
string is correct, and it appears to be, then don't worry about it,
just make sure the value you set for StartTimeUtc is correct. If you
have more trouble, let me know and I can try to send a small console
app?

Good luck,
Landon