Issue with trigger after DST

[arunprakashn]

Note: I have already gone through the FAQ section on DST impact with respect to the simple and cron jobs. I still have a problem.

We are using a simple schedule with 5-second intervals. If I move my system clock to 1 hour before manually to simulate the DST, The job trigger stops. It resumes only after an hour. I am sure that we are not using Cron schedule. Can anyone tell why this is happening?

 triggerBuilder.WithSimpleSchedule(s => s.WithIntervalInSeconds(intervalInSeconds).RepeatForever().WithMisfireHandlingInstructionNowWithExistingCount());

v3.2.3

To reproduce: Set up a simple schedule for 5 seconds. Print a console message when the job is fired. Change the time manually one hour back. You will notice that the triggers will stop.

[lahma]

Quartz calculates next fire time for trigger and waits for it. If you manually move the clock backwards it will take an hour to reach the pre-calculated fire time. You can experiment with calculation logic by using TriggerUtils.ComputeFireTimesBetween, but you should use a time span that has actual DST change in it.

[arunprakashn]

Hi @lahma ,

Please let me know if my understanding is correct. We have an application set up for a simple scheduler. It is to be triggered every 5 sec. If the DST happens and the time goes 1 hour backwards, are you saying, it wont impact the trigger? We faced some issue and I was trying to replicate the DST issue by moving my clock manually backwards and observed that the trigger stopped firing. You mean to say that the DST change of 1 hour backward and manual time change of 1 hour backwards are treated differently by the Quartz? In essence, you are confirming that the DST timeshift wont impact the simple 5 sec schedule. Is that correct?

[lahma]

Please use TriggerUtils.ComputeFireTimesBetween and print out the fire times to check how you trigger will behave in the given time range.

[GieltjE]

There still appears to be an issue every few time changes (and isn't just DST related), even when you expect the triggers to fire.
We use the same builder as mentioned above and rectify the system time every few hours.

There is a reliable way to trigger this:
1: create a trigger that fires every few seconds like the one above
2: start the program
3: set the system date to yesterday (don't change the time)
4: wait just a few seconds
5: set the system date back to today (don't change the time)
6: observe the job no longer getting triggered even though we are back in a logical time

As a slight complication, we cannot trust the "SystemEvents.TimeChanged" event, this one will simply not fire when running in a service (and in a few other undocumented scenarios, however running a form and overwriting WndProc and catching WM_TIMECHANGE works).
What is the best way to reset everything when the time changed event happens?

[GieltjE]

@lahma can we get some feedback on this issue?
I'm fully aware that this isn't going to be an easy fix, but triggers dying when a cheap quartz crystal on the motherboard gets rectified (NTP or manual) doesn't really sound right.

[lahma]

Maybe a failing test case would demonstrate the problem better and also offer easier startup point for investigation. Quartz has SystemTime which allows you to change time inside the test case.

[GieltjE]

There is now a test case #1490, only works for Windows as of now (don't know of any cross platform system time change code at the moment).