1-31/10 vs */10 dom

[lukescott]

I would think 1-31/10 vs */10 would be the same, but the code handles this case differently:

master/spec.go

    if s.Dom&starBit > 0 || s.Dow&starBit > 0 {
        return domMatch && dowMatch
    }
    return domMatch || dowMatch

Is there any doc somewhere that specifies why this is?

I'm asking because I added week year to my fork, and this is how I'm currently handling it:

wy-field/spec.go

    if s.Dom&starBit > 0 || s.Dow&starBit > 0 {
        return domMatch && dowMatch && woyMatch
    }
    return domMatch || (dowMatch && woyMatch)

I'm wondering if domMatch && dowMatch && woyMatch is correct in the starBit case.

[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.

[CompuRoot]

@williambanfield

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]

I think that we have to reference to the standard, instead of wikipedia. Below is the POSIX description:

If either the month or day of month is specified as an element or list, but the day of week is an , the month and day of month fields shall specify the days that match. If both month and day of month are specified as an , but day of week is an element or list, then only the specified days of the week match. Finally, if either the month or day of month is specified as an element or list, and the day of week is also specified as an element or list, then any day matching either the month and day of month, or the day of week, shall be matched.

It weird, but it the standard. Here is 10 years old discussion about this.

[williambanfield]

@CompuRoot The POSIX standard does not appear to handle slashes at all:

Each of these patterns can be either an <asterisk> (meaning all valid values), an element, or a list of elements separated by <comma> characters. An element shall be either a number or two numbers separated by a <hyphen-minus> (meaning an inclusive range).

[andrewbulin]

@williambanfield
Not sure if you still need this, but I had the same issue today and still needed the other behavior for a proof of concept. Other libraries may do what is needed, example based on my understanding thus far:

https://go.dev/play/p/WWM6g3kPuAv