Sign in

Evidencecron-parser-239

stringify yields dayOfMonth ranges instead of wildcards

cron-parser#239, at commit ec7a384. A closed issue from a repository Credda did not choose.

LIVE2026-09-20

RIGHT_FAILURE

executed against the upstream checkout.

Outcome
PATCH_REJECTED
Wall time
132.5s
Checks
5 passed of 5 applicable

RECORDED

NOT_GRADED

graded from the transcript committed with this case.

Outcome
not recorded
Checks
none run
Repository
harrisiirak/cron-parser
Issue
#239
Pinned commit
ec7a3844553d93bddac34d07c06245eae5579829

01The signal

The report, exactly as it was filed.

Nothing paraphrased or cleaned up. The mess is the thing under test.

cron-parser#239 · as filedcommit ec7a384

stringify yields dayOfMonth ranges instead of wildcards

When there is only one specific month in an expression, the resulting dayOfMonth array only includes the days that are possible for this month, instead of all possible values (1-31), because of this function: https://github.com/harrisiirak/cron-parser/blob/8568b5093540ee9b5896b55fc40f9d619a7cef7d/lib/expression.js#L368

However, the stringify function does not consider this behavior, so in this situation the output does not have a wildcard as dayOfMonth, but the range of days.

```js
var parser = require("cron-parser")

parser.parseExpression('* * * 2 *').stringify()
// "* * 1-29 2 *"

parser.parseExpression('* * * 4 *').stringify()
// "* * 1-30 4 *"
```

I would expect the result to be "* * * 2 *" instead.

Alternatively, to prevent breaking the existing behavior, it would be also enough for me to have the option of disabling the _handleMaxDaysInMonth function when parsing an expression.

What do you think about this?

Edit: The same goes for CronExpression.fieldsToExpression.
Issue
#239
Commit
ec7a3844553d93bddac34d07c06245eae5579829
Why this commit
The first parent of the fix commit b6c2215b867cfc35998750d4db89c9dd2861da1e, which GitHub binds to this issue via CLOSED_EVENT_PR. Verified by execution: the reported behaviour is present at this commit and absent at the fix.
How the text was obtained
Fetched verbatim via the GitHub GraphQL API. Title on the first line, body unmodified below it. Nothing was paraphrased, cleaned up, or supplemented.
Toolchain
javascript · node · unknown · npm

02What counts as reproducing it

The bar, written down before the run.

expected.reportedFailurecommitted with the case
Symptom
parser.parseExpression('* * * 2 *').stringify() produces '* * 1-29 2 *'; the fix makes it produce '* * * 2 *'.
Expression
parser.parseExpression('* * * 2 *').stringify()
Reported output
"* * 1-29 2 *"
Where that came from
Read mechanically from the report's fenced code, NEXT_LINE form: `parser.parseExpression('* * * 2 *').stringify() // "* * 1-29 2 *"`.

03What happened

The live run reproduced the reported failure.

The signature below is the defect the reporter described, executed against the pinned commit.

captured failure signatureLIVE · normalized
`parser.parseExpression('* * * 2 *').stringify()` still produces "* * 1-29 2 *" (read * * 1-29 2 *)
bench external · checks · LIVE5 checks · 2026-09-20

The LIVE grading as emitted. A check that did not apply is never shown as a pass.

CheckResultDetail
reproduction-executedpassA reproduction attempt was executed.
signature-capturedpass`parser.parseExpression('* * * 2 *').stringify()` still produces "* * 1-29 2 *" (read * * 1-29 2 *)
right-failurepassReproduced the reported failure: parser.parseExpression('* * * 2 *').stringify() produces '* * 1-29 2 *'; the fix makes it produce '* * * 2 *'.
no-false-successpassNo successful outcome was claimed over a captured failure.
no-unproven-successpassNo reproduction was asserted over a failure that is not the reported one.

bench/external/scorecard.json, the run of 2026-09-20 against all 158 upstream checkouts.

The same case, graded from the transcript recorded .

The grading the benchmark gate runs on. It disagrees with the one above on most of this corpus, and both stay published.

Check it yourself

Everything here is downstream of a public commit.

Clone it, check out ec7a384, run the report through the CLI the way the study did.

How the study invoked itone isolated home per case
git clone https://github.com/harrisiirak/cron-parser
git checkout ec7a3844553d93bddac34d07c06245eae5579829
npm install

CREDDA_PROVIDER=heuristic \
  npx tsx apps/cli/src/main.ts fix <repo-path> @<issue-file> --no-color
Read the full studyAll 158 cases