Download Latest Version Quartz.NET-3.19.1.zip (49.8 MB)
Email in envelope

Get an email when there's a new version of Quartz.NET

Home / v3.19.1
Name Modified Size InfoDownloads / 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

  • DailyTimeIntervalTrigger no longer spins on DST transition daysGetFireTimeAfter 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

Full Changelog: https://github.com/quartznet/quartznet/compare/v3.19.0...v3.19.1

Source: README.md, updated 2026-07-26