Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Handle DST better #317
This PR addresses the challenges of scheduling a daily event when considering daylight saving time transitions.
First, it's worth pointing out that the Quartz.net documentation's description of how DST is handled is wrong. It states multiple times (in the FAQ here, in the CronTrigger Tutorial here, in the Best Practices here, and probably in the API docs somewhere) that an occurrence in the spring-forward gap could be skipped and an occurrence in the fall-back overlap could execute twice. This is not actually the current implemented behavior.
The current implemented behavior is actually:
This behavior is ultimately coming from
While the spring behavior is fine, unfortunately the fall behavior is usually undesired in scheduling systems. When there are two occurrences of the same local time, a daily event should be expected to run at the first occurrence encountered, since time progresses in a forward direction. The first occurrence corresponds to the daylight time, not the standard time.
This PR addresses this by adding an overload of
Unit tests are included, and all existing unit tests pass.
The documentation should also be updated to reflect the actual behavior. Thanks.
I guess this PR flew under the radar for me somehow, so I'm to blame. The master now is ongoing work for 3.0 (now in alpha). I guess this would be quite safe to be included in 2.x maintenance branch. I can backport this unless you are willing to throw yet another pull request for the 2.x branch.
Also, reminder - you'll want to update the doc locations I pointed out originally, and any others that describe DST behavior. With this change, the rules are fixed to: