Cron Expression Generator & Parser

Cron is the scheduling syntax used by the Unix `cron` daemon and adopted, in slightly varying dialects, by an enormous range of tools: server crontabs, CI/CD pipelines (GitHub Actions, GitLab CI), cloud scheduled functions (AWS EventBridge, Google Cloud Scheduler), Kubernetes CronJobs, and application-level job schedulers. A standard cron expression has five space-separated fields, read left to right: minute (0–59), hour (0–23), day of month (1–31), month (1–12), and day of week (0–6, where 0 is Sunday — some implementations also accept 7 as a second way of writing Sunday). Getting the field order or a range wrong is a classic source of "why did this job not run" bugs, because the syntax is compact enough to be genuinely error-prone to read at a glance, especially once ranges and steps are involved. Each field accepts several kinds of value, and this tool's builder and parser both handle all of them: an asterisk (`*`) means "every value" for that field (every minute, every hour, and so on); a single number means exactly that value; a comma-separated list (`1,15,30`) means any of those specific values; a range (`1-5`) means every value from the first to the second, inclusive; and a step value (`*/15`) means every Nth value starting from the field's minimum — `*/15` in the minute field means minute 0, 15, 30, and 45. These forms can also combine, for example `1-5,10` (a range plus an extra value) or `*/2` in the month field (every second month). The builder direction turns a set of friendly dropdown choices into the compact expression string live, so you never have to remember the field order or the meaning of a bare `*` versus a comma list yourself — pick "every 15 minutes" for the minute field and "weekdays" for the day-of-week field, and the tool assembles `*/15 * * * 1-5` for you automatically as each choice changes. The parser direction runs in reverse: paste an existing expression you found in a crontab, a CI config, or a colleague's code, and a hand-rolled interpreter reads all five fields and produces a human-readable sentence describing exactly when it fires — handling every combination of `*`, single values, lists, ranges, and steps across all five fields, entirely with string parsing and arithmetic, no external cron library. One genuinely confusing corner of the cron specification, worth understanding rather than just working around: when both the day-of-month field and the day-of-week field are restricted (i.e. neither is a bare `*`), most cron implementations treat them as an OR, not an AND — the job runs on days that match either condition, not only days that match both. For example, `0 0 1 * 1` does not mean "only if the 1st of the month happens to fall on a Monday"; it means "midnight on the 1st of every month, OR every Monday, whichever comes first each week." This tool's parser calls this out explicitly in its plain-English description whenever both fields are restricted simultaneously, rather than silently describing it as an AND condition, which is the most common misreading of cron syntax.