1-31/10 vs */10 dom

[robfig]

1-31/10 vs */10 dom

[robfig]

I believe that is due to my reading of https://en.wikipedia.org/wiki/Cron:

While normally the job is executed when the time/date specification fields all match the current time and date, there is one exception: if both "day of month" (field 3) and "day of week" (field 5) are restricted (not "*"), then one or both must match the current day.[3]

[lukescott]

Wouldn't that mean strictly *, not */10? With * meaning all and Dom and Dow being an OR, * being a special case makes sense since you can't use a value outside the range.

I'm wondering whether starBit should be set in the case of */10 since it really does't mean all.

[robfig]

Yeah, I agree

[lukescott]

@robfig when I remove starBit when step > 1 the following test fails:

spec_test.go:164: Mon Jul 9 23:35 2012, "0 0 0 */5 Apr,Aug,Oct Mon": (expected) 2012-08-06 00:00:00 +0000 UTC != 2012-08-01 00:00:00 +0000 UTC (actual)

Just want to make sure I'm not missing something here. Since Dom and Dow is an OR, it actually should be 2012-08-01 00:00:00 +0000 UTC right?

Changes made:

diff --git a/parser.go b/parser.go
index 01c4c3a..40b824b 100644
--- a/parser.go
+++ b/parser.go
@@ -225,6 +225,10 @@ func getRange(expr string, r bounds) (uint64, error) {
                if singleDigit {
                        end = r.max
                }
+
+               if step > 1 {
+                       extra_star = 0
+               }
        default:
                return 0, fmt.Errorf("Too many slashes: %s", expr)
        }

[robfig]

I imagine the test is wrong in that case

[robfig]

This is fixed on v3 branch.

[williambanfield]

Fwiw, I think that the old behavior may have been correct here? The Wikipedia page looks to have been updated to match the man page:

Wikipedia:

While normally the job is executed when the time/date specification fields all match the current time and date, there is one exception: if both "day of month" (field 3) and "day of week" (field 5) are restricted (not contain "*"), then one or both must match the current day.[7]

man page:

The day of a command's execution can be specified in the
following two fields — 'day of month', and 'day of week'. If
both fields are restricted (i.e., do not contain the "*"
character), the command will be run when either field matches the
current time. For example,
"30 4 1,15 * 5" would cause a command to be run at 4:30 am on the
1st and 15th of each month, plus every Friday.

Meaning */10, which does contain a star, should be parsed as 'unrestricted', leading to the AND behavior not the OR behavior.

Came here after looking for a way to implement the behavior outlined in this blog post and wondering if this library implemented the AND or the OR.

It's pretty esoteric behavior but I figured I'd point it out since I noticed.