let traits decide how the two day fields combine - #50
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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:So the reported expression now resolves to
2021-01-01under 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 inoperator==, since0 0 0 1-31 1 1and0 0 0 * 1 1set 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.