Can't schedule CronWorkflows with workaround for first day of month (cron "if")

[JPZ13]

Pre-requisites

• I have double-checked my configuration
• I have tested with the :latest image tag (i.e. quay.io/argoproj/workflow-controller:latest) and can confirm the issue still exists on :latest. If not, I have explained why, in detail, in my description below.
• I have searched existing issues and could not find a match for this bug
• I'd like to contribute the fix myself (see contributing guide)

What happened/what did you expect to happen?

When using the CRON workaround for scheduling a workflow on the first Monday of the month, the workflow-controller and the UI display differently for when the Workflow will run next.

For a CronWorkflow with the following schedule:

spec:
  workflowSpec:
    arguments:
      parameters:
        - name: cluster
          value: -------
        - name: max_version
          value: '1.28'
        - name: region
          value: us-east-1
    workflowTemplateRef:
      name: cluster-update
  schedule: 0 4 */100,1-7 * TUE
  concurrencyPolicy: Replace
  startingDeadlineSeconds: 0
  successfulJobsHistoryLimit: 1
  failedJobsHistoryLimit: 1
  timezone: America/Detroit

We would expect the next scheduled time to be in however many days to the first Tuesday of the month, but we're seeing that it shows as being scheduled the Tuesday of this week:

This issue stems from this discussion on Slack: https://cloud-native.slack.com/archives/C01QW9QSSSK/p1715619295295039

Note: I did check that the controller cron package we use is unmaintained with no new commits landing to the default branch or releases in the last four years: https://isitmaintained.com/project/robfig/cron. Maybe upgrading to a new package would solve

Version

latest

Paste a small workflow that reproduces the issue. We must be able to run the workflow; don't enter a workflows that uses private images.

See above snippet

Logs from the workflow controller

Not needed

Logs from in your workflow's wait container

Not needed

[agilgur5]

Note: I did check that the controller cron package we use is unmaintained with no new commits landing to the default branch or releases in the last four years: https://isitmaintained.com/project/robfig/cron. Maybe upgrading to a new package would solve

It's the same library that k8s CronJobs use and is well known as unmaintained, see #8348 as I linked in the Slack thread. They used this approach because of that issue.

We would expect the next scheduled time to be in however many days to the first Tuesday of the month, but we're seeing that it shows as being scheduled the Tuesday of this week:

Per Slack thread, the next scheduled time is the same in the CLI and UI so is not a UI-only bug.

Also per thread, this syntax may be considered non-standard due to buggy implementations per https://crontab.guru/tips.html (tip 1) and https://crontab.guru/cron-bug.html, the "if" part of the cron syntax is a bit wacky.
As such, I'm not sure I'd consider this a bug, since an implementation might intentionally do that to match. Note that per the thread, both the UI and the CLI had the same next run, so that would explain why they're equivalent despite the UI's cron library supporting some non-standard syntax.

To be exact for better readability + accessibility and searchability:

• Cron Expression: 0 4 */100,1-7 * TUE, https://crontab.guru/#0_4_*/100,1-7_*_TUE
• Crontab.guru human-readable: "At 04:00 on every 100th day-of-month and every day-of-month from 1 through 7 if it's on Tuesday.” (emphasis mine)
  • Next run is the first Tuesday of next month: 2024-06-04 04:00:00
• Workflows UI human-readable: "At 04:00 AM, every 100 days and 1 through 7, and on Tuesday" (emphasis mine)
  • Next run is next Tuesday this month: 2024-05-13 04:00:00 ("14h8m")
  • Workflows CLI does not have human-readable text, but does show next run same as the UI: 2024-05-13 04:00:00 ("14h8m")