Skip to content

let traits decide how the two day fields combine - #50

Merged
mariusbancila merged 1 commit into
masterfrom
feature/day-field-rule
Aug 12, 2026
Merged

let traits decide how the two day fields combine#50
mariusbancila merged 1 commit into
masterfrom
feature/day-field-rule

Conversation

@mariusbancila

@mariusbancila mariusbancila commented Aug 12, 2026

Copy link
Copy Markdown
Owner

0 0 0 1 1 1 - the 1st of January, and Mondays in January — returned 2024-01-01, because croncpp required a date to match both day fields. Every cron dialect disagrees with that, and they disagree with each other too: POSIX matches a date against either field when both are restricted, while Quartz refuses the expression outright and wants ? in one of them.

Rather than pick a winner, each traits type now states the rule of the dialect it describes, via a new CRON_DAY_FIELD_RULE:

┌────────────────────────────────────────┬──────────────────────────────────────────┐
│                 Traits                 │                   Rule                   │
├────────────────────────────────────────┼──────────────────────────────────────────┤
│ cron_standard_traits                   │ either, as in POSIX cron                 │
├────────────────────────────────────────┼──────────────────────────────────────────┤
│ cron_quartz_traits, cron_oracle_traits │ reject; one field has to be ?            │
├────────────────────────────────────────┼──────────────────────────────────────────┤
│ traits declaring nothing               │ intersect, croncpp's behaviour until now │
└────────────────────────────────────────┴──────────────────────────────────────────┘

So the reported expression now resolves to 2021-01-01 under the standard traits, and is rejected with a clear message under the other two. Traits written before this change keep intersecting, so custom traits are unaffected — same opt-in shape as the year field.

A field counts as restricted unless it is literally * or ?. That distinction is recorded at parse time and included in operator==, since 0 0 0 1-31 1 1 and 0 0 0 * 1 1 set identical bits but no longer mean the same thing.

This is a behaviour change for expressions restricting both day fields under the standard traits, and a new error under quartz and oracle. Nothing in the existing suite moved - none of it restricts both fields, but it belongs in the release notes.

New test_day_fields.cpp.

Fixes #12.

@mariusbancila
mariusbancila merged commit 77147a6 into master Aug 12, 2026
17 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Wrong timestamp when set day of month and day of week

1 participant