-
Notifications
You must be signed in to change notification settings - Fork 156
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
.stringify()
and .fields
do not support nthDayOfWeek
expressions (e.g. 0 9 * * 1#2
)
#349
Comments
Upon further testing I realized that even if you do not convert to fields, the original expression is unable to See the following failing test I've written: test("stringify expressions with `nthDayOfWeek` configuration", async () => {
// Every month on the second Monday at 9am.
const expression = "0 9 * * 1#2";
const parsedExpression = parseExpression(expression);
expect(parsedExpression.stringify(false)).toEqual(expression);
// Expected: "0 9 * * 1#2"
// Received: "0 9 * * 1"
}); |
Jackman3005
changed the title
Expressions with
May 9, 2024
nthDayOfWeek
(0 9 * * 1#2
) are incorrect when rebuilt from fields
.stringify()
and .fields
do not support nthDayOfWeek
expressions (0 9 * * 1#2
)
Jackman3005
changed the title
May 9, 2024
.stringify()
and .fields
do not support nthDayOfWeek
expressions (0 9 * * 1#2
).stringify()
and .fields
do not support nthDayOfWeek
expressions (e.g. 0 9 * * 1#2
)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Note: The library does correctly parse the expression and provide correct
next()
dates fornthDayOfWeek
expressions.Issue
Given the expression
0 9 * * 1#2
which represent "Once a month on the first Monday of the Month at 9am". When the expression's fields are extracted via.fields
and then the expression is rebuilt and stringified, it loses thenthDayOfWeek
configuration and results in0 9 * * 1
, which is incorrect.See the following failing test I wrote and relevant console output:
Possible solution
The
nthDayOfWeek
configuration is stored in the private_options
field of the expression. I'm not sure of other consequences that might arise, but it seems to me this should be moved from_options
tofields
so it can be passed through and used infieldsToExpression
to correctly rebuild the expression state.The text was updated successfully, but these errors were encountered: