| Name | Modified | Size | Downloads / Week |
|---|---|---|---|
| Parent folder | |||
| Quartz.NET-3.19.1.zip | 2026-07-26 | 49.8 MB | |
| README.md | 2026-07-26 | 2.6 kB | |
| v3.19.1 source code.tar.gz | 2026-07-26 | 5.3 MB | |
| v3.19.1 source code.zip | 2026-07-26 | 5.9 MB | |
| Totals: 4 Items | 61.0 MB | 2 | |
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
DailyTimeIntervalTriggerno longer spins on DST transition days —GetFireTimeAftercould return a time at or before the one it was given, which makesQuartzSchedulerThreadfire 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 toStartTimeOfDayreused whatever UTC offset the previous fire time carried (so in time zones that move the clock at midnight, such as Chile,StartTimeOfDay00: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 returnednulluntil somebody had calledGetScheduler()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 howSchedulerRepositoryindexes 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 https://github.com/quartznet/quartznet/pull/3188
- Fix DailyTimeIntervalTrigger infinite fire loop during DST spring-forward (#332) by @lahma in https://github.com/quartznet/quartznet/pull/3190
Full Changelog: https://github.com/quartznet/quartznet/compare/v3.19.0...v3.19.1