0

I recently upgraded from 1.x to the latest version 2.1.2. I ran the db scripts and made the necessary code changes and we're just testing it now. Everything seems to work as expected with one odd exception. We have a little UI that we query the qrtz_trigger table for so we can see all the schedules when things will run.

When I schedule a Job with a daily CRON trigger it will run at the correct time the first run, but the subsequent time it will be off by one hour. So for example say I schedule a daily job to run at 2:30 PM every day, my cron expression looks like:

0 30 14 ? * MON-SUN

And the CRON expression appears as such in the db as well. When I look in the qrtz_triggers table I see the following (converted from ticks):

  • NEXT_FIRE_TIME: 2013-08-15 14:30:00.000
  • PREV_FIRE_TIME: NULL

So far so good. But then the trigger fires, runs the job and the qrtz_triggers table is updated to:

  • NEXT_FIRE_TIME: 2013-08-16 13:30:00.000
  • PREV_FIRE_TIME: 2013-08-15 14:30:00.000

We keep all our servers running on UTC to avoid confusion. Is this a bug? What might be going on here? We don't see this behavior in 1.x

snappymcsnap
  • 2,050
  • 2
  • 29
  • 53
  • @gunr2171 The server that quartz (and it's db) is runnign on is UTC, they care nothing for DST – snappymcsnap Aug 15 '13 at 15:50
  • How do you convert from ticks? – Daniel Gabriel Aug 15 '13 at 16:47
  • @Daneil Gabriel we have a utility function that we use in our quartz dbs that converts from ticks to DateTime. We don't use it for anything except to make it easier to debug stuff (looking at an 18 digit number is not much help). But even if I don't use that function and just look at the raw numbers in the db you can see that it is not correct (off an hour) – snappymcsnap Aug 15 '13 at 17:40

0 Answers0