Recurrence.RecurrenceRule.Parse(...) does not resolve with the current using Quartz.Impl.Recurrence; and will not compile (there is no Recurrence namespace in scope here). Use RecurrenceRule.Parse(...) (or fully qualify Quartz.Impl.Recurrence.RecurrenceRule.Parse) in both Validate() and GetParsedRule().

FinalFireTimeUtc converts a local UNTIL value using TimeZone.BaseUtcOffset, which is incorrect for dates that fall under DST (and can produce the wrong UTC instant). Convert using the time zone’s offset for the specific local timestamp (and handle ambiguous/invalid local times consistently with the rule engine’s conversion logic).

Validate() only catches FormatException, but the parser uses int.Parse(...) (and other operations) that can also throw OverflowException/ArgumentException. Consider catching those as well (or catching Exception and wrapping) so callers consistently receive a SchedulerException for invalid RRULE input.

These DST tests use TimeZoneInfo.FindSystemTimeZoneById("Eastern Standard Time"), which is Windows-only and will fail on Linux/macOS CI. Use the existing cross-platform helper used elsewhere in the test suite (e.g., TimeZoneUtil.FindTimeZoneById(...) or TZConvert.GetTimeZoneInfo(...)).

MaxIterations = 1000 causes GetNextOccurrence/GetNthOccurrence to return null for valid RRULEs where the next matching occurrence is more than 1000 base periods away (e.g., FREQ=SECONDLY;BYMONTH=12 when evaluated in January would require scanning ~11 months of seconds). The evaluation should be able to advance to the next possible matching period based on limiting BY* rules (or otherwise ensure the search bound cannot truncate valid schedules).

RRULE parsing currently accepts out-of-range BY* values (e.g., BYMONTH=0,13) without failing, and later evaluation often silently skips them (producing an empty candidate set / no firings). To avoid “valid but never fires” configurations and match existing Quartz parsing behavior (e.g., cron), validate BY* ranges during Parse/ParseIntList and throw FormatException on invalid values.

In WithRecurrenceSchedule(..., Action<RecurrenceScheduleBuilder> action), the action parameter is non-nullable but invoked via action?.Invoke(...). Other TriggerBuilder schedule extensions treat the action as required (non-nullable + direct invocation). Either make the parameter nullable (Action<...>?) or remove the null-conditional to match the established pattern (e.g., CronScheduleTriggerBuilderExtensions).

FinalFireTimeUtc should be the last scheduled fire time on or before EndTimeUtc. Returning EndTimeUtc directly can be incorrect when EndTimeUtc is not aligned to the RRULE (e.g., daily at 09:00 with EndTimeUtc at 08:00). Consider computing the last occurrence <= EndTimeUtc (similar to CronTriggerImpl/CalendarIntervalTriggerImpl behavior) instead of returning the boundary value.

FinalFireTimeUtc returns the UNTIL boundary value, but UNTIL is an upper bound—not necessarily an occurrence. If UNTIL doesn't land on an actual scheduled fire time, this will report a final fire time that will never fire. Consider computing the last occurrence <= UNTIL (and <= EndTimeUtc if set) instead.

Applying BYSETPOS uses List.Contains() to deduplicate, which is O(n) per element. If the expanded candidate set is large, this becomes O(n^2). Consider using a HashSet (or tracking the last-added value after sorting) to dedupe in O(1) per element.

TimeZoneInfo.FindSystemTimeZoneById("America/New_York") is not portable across OSes (Windows typically expects Windows IDs, Linux/macOS use IANA). Consider using Quartz.Util.TimeZoneUtil.FindTimeZoneById (or document the expected ID format) so the example works cross-platform.

The comment says this enables cross-platform timezone support, but TimeZoneInfo.FindSystemTimeZoneById will still fail when deserializing an ID not present on the current OS (e.g., Windows vs IANA IDs). Either adjust the comment to match the existing triggers’ caveat, or resolve via TimeZoneUtil.FindTimeZoneById to improve portability.

The text says “two misfire instructions” but three bullets are listed (including IgnoreMisfirePolicy). Consider rewording to clarify that there are two RecurrenceTrigger-specific instructions, plus the generic IgnoreMisfirePolicy.

GetNthOccurrence caps the search to MaxIterations (1000) periods. For COUNT-based rules with large COUNT values (e.g., daily COUNT>1000), this can return null even though the Nth occurrence exists, which makes FinalFireTimeUtc incorrect. Consider making the iteration bound adaptive to n/rule density (or explicitly validating/rejecting COUNT values that exceed the supported bound with a clear exception).

In this project, other trigger serializers (CronTriggerSerializer, SimpleTriggerSerializer, etc.) are public, but RecurrenceTriggerSerializer is internal. If consumers are expected to be able to reference/extend trigger serializers consistently, this should likely be public as well (or make the visibility consistent across all serializers).

In this project, other trigger serializers (CronTriggerSerializer, SimpleTriggerSerializer, etc.) are public, but RecurrenceTriggerSerializer is internal. If consumers are expected to be able to reference/extend trigger serializers consistently, this should likely be public as well (or make the visibility consistent across all serializers).

ExpandWeekly states "everything else limits" but the implementation only applies a BYMONTH filter and then expands times. As written, other parsed BY* limit rules (e.g., BYMONTHDAY) are ignored for WEEKLY rules, which can produce incorrect candidate sets and contradicts the method comment. Consider applying the remaining limit rules for WEEKLY (or tightening the parser to reject unsupported BY* combinations) and/or updating the comment to match actual behavior.

In GetNthOccurrence, the comment says the iteration bound is "capped at a reasonable maximum", but maxPeriods is computed via Math.Max(MaxIterations, limit + MaxIterations), which grows without bound as COUNT increases. This can make FinalFireTimeUtc (which calls GetNthOccurrence for COUNT rules) potentially very expensive for large COUNT values. Consider enforcing a real upper bound (e.g., a hard cap, or a cap based on the same "give up" year logic used by other triggers) and aligning the comment with the actual behavior.

Validate() enforces a 512-character RRULE limit based on the ADO.NET SIMPROP_TRIGGERS schema. Since Validate() is called regardless of the configured job store, this prevents using longer RRULE strings even with RAMJobStore or JSON-only scenarios. Consider moving this constraint into the ADO persistence path (e.g., the persistence delegate / JobStoreSupport) or making it conditional so non-ADO usage isn’t artificially restricted.

The comment refers to the SIMPROP_TRIGGERS column as STRING_PROP_1, but the Quartz schema uses STR_PROP_1 (e.g., database/sqlserver_schema_10_to_20_upgrade.sql defines STR_PROP_1 VARCHAR(512)). Please update the comment to the correct column name to avoid confusion when troubleshooting persistence issues.

This tutorial says the RRULE is stored in the STRING_PROP_1 column, but the actual QRTZ_SIMPROP_TRIGGERS schema uses STR_PROP_1 (length 512). Please correct the column name in the docs to match the database scripts.

ParseByDay accepts any integer ordinal (e.g. BYDAY=100MO) without validating the RFC 5545 allowed range (typically -53..53, excluding 0). This can silently create rules that never produce occurrences instead of failing fast like the other BY* parsers do. Consider validating the ordinal range and throwing FormatException for out-of-range values.

The docs example uses TimeZoneUtil.FindTimeZoneById("America/New_York"), but TimeZoneUtil only aliases a limited set of Windows/IANA IDs and does not include America/New_York. On Windows this will throw TimeZoneNotFoundException. Consider switching the example to an ID that TimeZoneUtil can resolve cross-platform (e.g., Eastern Standard Time / US/Eastern) and/or add a note about using Quartz.Plugins.TimeZoneConverter when relying on IANA IDs on Windows.

Recurrence.RecurrenceRule.Parse(...) relies on namespace-resolution to bind Recurrence to the sibling namespace Quartz.Impl.Recurrence, which is non-obvious and easy to misread as a type reference. For clarity and to avoid future ambiguity (e.g., if a Recurrence type is introduced), prefer fully qualifying the type (Quartz.Impl.Recurrence.RecurrenceRule.Parse(...)) or adding a using Recurrence = Quartz.Impl.Recurrence; alias and using that consistently.

Same namespace-resolution concern here: Recurrence.RecurrenceRule.Parse(...) is hard to read and depends on resolving Recurrence as the Quartz.Impl.Recurrence namespace. Consider fully qualifying the type or using a namespace alias for clarity.