Bump Quartz.Extensions.Hosting from 3.19.0 to 3.19.1

[dependabot]

Pinned Quartz.Extensions.Hosting at 3.19.1.

Release notes

Sourced from Quartz.Extensions.Hosting's releases.

3.19.1

Quartz.NET 3.19.1 is a small bug fix release with two targeted fixes: DailyTimeIntervalTrigger no longer gets stuck in an infinite fire loop on DST spring-forward days, and StdSchedulerFactory.GetScheduler(schedName) now creates the scheduler when the name asked for is its own. There are no API or schema changes, so it is a drop-in upgrade from 3.19.0.

Highlights

• DailyTimeIntervalTrigger no longer spins on DST transition days — GetFireTimeAfter could return a time at or before the one it was given, which makes QuartzSchedulerThread fire the trigger, compute the same next fire time, and fire again — pinning a CPU core and flooding the log. Two independent causes, both on a spring-forward day: the DST correction added for #​1114 was applied to every interval size and in either direction (so every interval of an hour or less was affected, in every DST time zone), and the daily rollover to StartTimeOfDay reused whatever UTC offset the previous fire time carried (so in time zones that move the clock at midnight, such as Chile, StartTimeOfDay 00:00 resolved to an instant before the transition — the same instant that was passed in). Verified across 3024 combinations of 12 time zones, both transitions, 21 intervals and 6 start times: 468 combinations produced non-advancing fire times before, none do now. (#​3190, fixes #​332)
  • Behavior change worth noting: the same fix stops sub-hour triggers silently dropping the last hour of a fall-back day. A 5-minute trigger now fires 300 times through the 25-hour day, ending at 23:55 local, instead of 288 times ending at 22:55.
• StdSchedulerFactory.GetScheduler(schedName) creates its own scheduler — asking a factory for the scheduler it is configured to produce returned null until somebody had called GetScheduler() first. It now creates it. Any other name stays a pure lookup, so probing for a scheduler somebody else owns still has no side effects, and the name comparison is case-insensitive to match how SchedulerRepository indexes names. The DI factory has behaved this way since #​2845; this brings the property-configured factory in line. (#​3188, reported in #​2786, originally proposed in #​360)

What's Changed

• Create the scheduler when it is looked up by its own name (#​360) by @​lahma in Create the scheduler when it is looked up by its own name (#360) quartznet/quartznet#3188
• Fix DailyTimeIntervalTrigger infinite fire loop during DST spring-forward (#​332) by @​lahma in Fix DailyTimeIntervalTrigger infinite fire loop during DST spring-forward (#332) quartznet/quartznet#3190

Full Changelog: quartznet/quartznet@v3.19.0...v3.19.1

Commits viewable in compare view.

[Sev7eNup]

@dependabot rebase

[dependabot]

Superseded by #160.