2
votes

I'm stuck on an issue with the Quartz Scheduler. I tried to ask terracota in their forum but i get no answer ...

I use a Java Quartz and DailyTimeIntervalScheduleBuilder as following

 DailyTimeIntervalScheduleBuilder dti = dailyTimeIntervalSchedule()
         .startingDailyAt(new TimeOfDay(0, 30))
         .endingDailyAt(new TimeOfDay(7, 0))
         .onEveryDay()
         .withIntervalInHours(2)
         .withMisfireHandlingInstructionFireAndProceed();

As you can see, i want the trigger to fire every day between 00:30 and 07:00 every two hours.

On 'normal' days, the trigger fires like this :

 Sat Mar 01 00:30:00 CET 2014
 Sat Mar 01 02:30:00 CET 2014
 Sat Mar 01 04:30:00 CET 2014

But with DST :

 Sun Mar 30 00:30:00 CEST 2014
 Sun Mar 30 03:30:00 CEST 2014
 Sun Mar 30 05:30:00 CEST 2014

I understand why the timestamp calculates for the second firing happens at 03:30 and not at 02:30 but why the trigger don't 're-adjust' the next firing at 04:30 ? Actually i guess it is because

...in spring the clock jumps forward from the last moment of 01:59 standard time to 03:00 DST and that day has 23 hours, whereas in autumn the clock jumps backward from the last moment of 01:59 DST to 01:00 standard time, repeating that hour, and that day has 25 hours.[37] A digital display of local time does not read 02:00 exactly at the shift to summertime, but instead jumps from 01:59:59.9 forward to 03:00:00.0.

Wikipedia

How can i deal to force the trigger to 're-adjust' ?

PS: I want it to fire at 00:30, 03:00, 04:30, ... this day

1

1 Answers

2
votes

Actually, on the spring-forward transition day for CET/CEST, it would look like this:

Sun Mar 30 00:30:00 CET 2014
Sun Mar 30 03:30:00 CEST 2014
Sun Mar 30 05:30:00 CEST 2014

This is following your instructions, as 120 minutes have actually elapsed between each of these values.

If you were to adjust as you suggested:

Sun Mar 30 00:30:00 CET 2014
Sun Mar 30 03:00:00 CEST 2014
Sun Mar 30 04:30:00 CEST 2014
Sun Mar 30 06:30:00 CEST 2014

Then there would only be 90 minutes elapsed between the first two points - which isn't what you asked the scheduler to do.

Another common way of adjusting is to only move one of the affected values:

Sun Mar 30 00:30:00 CET 2014
Sun Mar 30 03:30:00 CEST 2014
Sun Mar 30 04:30:00 CEST 2014
Sun Mar 30 06:30:00 CEST 2014

OR

Sun Mar 30 00:30:00 CET 2014
Sun Mar 30 01:30:00 CET 2014
Sun Mar 30 04:30:00 CEST 2014
Sun Mar 30 06:30:00 CEST 2014

Then you either elapse [120, 60, 120], or [60, 120, 120]. Sometimes this is more palatable because the minutes align. Sometimes not.

Also, consider that on the day of the fall-back transition, you have a related concern. If you don't adjust, it will run like this:

Sun Oct 26 00:30:00 CEST 2014
Sun Oct 26 02:30:00 CEST 2014
Sun Oct 26 03:30:00 CET 2014
Sun Oct 26 05:30:00 CET 2014

Those are 120 minutes apart. And again, you can choose to adjust if you like so it runs like this:

Sun Oct 26 00:30:00 CEST 2014
Sun Oct 26 02:30:00 CEST 2014
Sun Oct 26 04:30:00 CET 2014
Sun Oct 26 06:30:00 CET 2014

But now the intervals are [120,60,120] - even though the times align.

TL;DR - The scheduler can't make this decision for you. You need to decide what behavior you want and adjust for that behavior accordingly. If you leave it alone, it will simply follow your instructions of running every 2 hours within the window you specified, regardless of whether it falls exactly at the same points every day that it runs.

If you are having trouble visualizing this, consider the charts shown in the DST tag wiki.