You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Note: The library does correctly parse the expression and provide correct next() dates for nthDayOfWeek 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 the nthDayOfWeek configuration and results in 0 9 * * 1, which is incorrect.
See the following failing test I wrote and relevant console output:
test("parsing `nthDayOfWeek` expressions to fields and rebuilding from fields does not change the expression",()=>{// Every month on the second Tuesday at 9am.constexpression="0 9 * * 2#2";constfields=parseExpression(expression).fields;console.log("Fields: ",fields);// Fields: {// second: [ 0 ],// minute: [ 0 ],// hour: [ 9 ],// dayOfMonth: [// 1, 2, 3, 4, 5, 6, 7, 8, 9,// 10, 11, 12, 13, 14, 15, 16, 17, 18,// 19, 20, 21, 22, 23, 24, 25, 26, 27,// 28, 29, 30, 31// ],// month: [// 1, 2, 3, 4, 5,// 6, 7, 8, 9, 10,// 11, 12// ],// dayOfWeek: [ 2 ]// }constexpressionFromFields=fieldsToExpression(fields).stringify(false);expect(expressionFromFields).toEqual(expression);// <--- Expectation fails// Expected: "0 9 * * 2#2"// Received: "0 9 * * 2"});
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 to fields so it can be passed through and used in fieldsToExpression to correctly rebuild the expression state.
The text was updated successfully, but these errors were encountered:
Upon further testing I realized that even if you do not convert to fields, the original expression is unable to stringify(..)nthDayOfWeek expressions correctly.
See the following failing test I've written:
test("stringify expressions with `nthDayOfWeek` configuration",async()=>{// Every month on the second Monday at 9am.constexpression="0 9 * * 1#2";constparsedExpression=parseExpression(expression);expect(parsedExpression.stringify(false)).toEqual(expression);// Expected: "0 9 * * 1#2"// Received: "0 9 * * 1"});
Jackman3005
changed the title
Expressions with nthDayOfWeek (0 9 * * 1#2) are incorrect when rebuilt from fields.stringify() and .fields do not support nthDayOfWeek expressions (0 9 * * 1#2)
May 9, 2024
Jackman3005
changed the title
.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)
May 9, 2024
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: