Does the cron parser support Quartz or six-field expressions?

No. The Cron Parser targets classic numeric five-field crontab syntax. Quartz, cloud schedulers, and other products add seconds, years, question marks, or different weekday rules, so the same five-field string can mean something else or be rejected entirely.

What happens when both day-of-month and day-of-week are restricted?

Traditional cron matches when either restricted day field matches. The parser follows that documented OR behavior rather than requiring both fields to match at once.

Which time zone is used for the next five run times?

The next-run engine enumerates UTC instants and formats them in your browser's local time. The actual scheduler uses its own configured time zone, which you must verify separately.

Why is my expression rejected when it looks valid?

Common reasons include extra command text after the five fields, descending ranges, zero or negative steps, empty list items, names such as JAN or MON, or values outside the conventional field range. Each rejection names the offending field so you can correct it directly.

Cron Parser Example: 5 Real Schedules Decoded

A cron parser example takes a five-field expression like */15 9-17 * * 1-5, expands each field into its concrete value set, and lists the next five instants the schedule would actually fire. Classic cron syntax is compact on purpose, but that compactness is also where most mistakes hide: one field out of order, an inverted range, or a step that starts at the wrong base value can silently move a backup job from every fifteen minutes during business hours to once a day at midnight. A parser turns that ambiguity into three concrete artifacts — a normalized expression, a per-field summary in plain language, and a list of upcoming run times in both your browser's local time and ISO UTC — so you can verify the schedule before it ships. The Cron Parser is built for exactly this workflow, accepting the portable numeric five-field format documented in Cronie's crontab(5) reference and used by most Unix-style schedulers. Each example in this article uses the same five-field structure, so the field positions, ranges, and normalization rules stay consistent across schedulers.

Cron itself is just a five-field schedule string. The scheduler reads it once at registration, then wakes up every minute to ask whether the current minute matches every field at once. The parser does the same job ahead of time: it expands each field into the set of values it could match and walks forward through candidate minutes until it has five real hits. That makes it easy to confirm "every weekday at 09:30" actually means Monday through Friday at 09:30, and not "every day at 09:30 on whichever weekday the calendar happens to land on."

Anatomy of a Five-Field Cron Expression

Every expression has exactly five whitespace-separated fields, in this fixed order:

Minute — 0 through 59
Hour — 0 through 23 (24-hour clock)
Day of month — 1 through 31
Month — 1 through 12
Day of week — 0 through 7, where both 0 and 7 mean Sunday

The order is not negotiable. Writing * * * * 5 means "every minute on Friday," not "every fifth minute of every day." The Cron Parser enforces that ordering and rejects anything other than exactly five fields, which is what stops a stray pipe, redirect, or command argument from being silently absorbed into the schedule.

What the Parser Returns for Each Example

After you paste an expression, three things appear:

Normalized expression — extra spaces are stripped, lists are sorted, ranges stay inclusive, and weekday 7 is rewritten as 0 so Sunday is not duplicated.
Field summary — each field is rewritten as a plain list of selected values, like 0,15,30,45 for */15 or 8-12 rendered as the range itself.
Next five runs — five future instants that match every field simultaneously, displayed in your browser's local time and as ISO UTC strings.

The local and UTC pair is intentional. The browser shows the time you would see on a wall clock, and the UTC timestamp lets you compare against logs, container images, and other servers without daylight-saving confusion. Calendar validity is handled by the underlying JavaScript Date logic, so a day-of-month of 31 naturally skips months without a 31st, and February rules respect leap years.

Walk Through Five Real Cron Expressions

This is the core "cron parser example" workflow: take a schedule, paste it in, and read the field summary alongside the next five runs.

Paste a five-field expression in minute, hour, day-of-month, month, day-of-week order.
Use numeric values, * wildcards, comma lists, inclusive ranges, or steps such as */15.
Read the normalized expression, field summary, and the next five matching local and UTC run times.
Cross-check the UTC timestamps against the documentation and time zone of the scheduler that will actually execute the job.

Example 1 — every fifteen minutes during business hours on weekdays.

*/15 9-17 * * 1-5

Field 1, */15, selects 0,15,30,45 in the minute slot. Field 2, 9-17, selects hours 9,10,11,12,13,14,15,16,17. Field 3, *, selects 1-31. Field 4, *, selects 1-12. Field 5, 1-5, selects weekdays 1,2,3,4,5. The next five runs land on the next weekday inside 09:00 through 17:59 at minute 0, 15, 30, or 45. If today is Friday at 14:07 local, the next five hits are 14:15, 14:30, 14:45, 15:00, and 15:15 on that same Friday.

Example 2 — every Monday at 08:00.

0 8 * * 1

Minute 0, hour 8, day *, month *, weekday 1. The parser reports the normalized form 0 8 * * 1 and the summary 0 | 8 | 1-31 | 1-12 | 1. The next five runs are the next five Mondays at 08:00 local time with the matching ISO UTC timestamps, which lets you confirm the host that runs the job is set to the same time zone the browser is using.

Example 3 — the 21st of every month at 03:30.

30 3 21 * *

This is a classic day-rule trap. Day 21 is restricted and weekday * is unrestricted. With a wildcard weekday the rule means "every month on the 21st at 03:30," which lands on whatever weekday that date happens to be. The parser lists the next five occurrences of the 21st, including dates that fall on weekends, so the resulting runs include both 21 February and 21 March on whatever weekday those dates happen to land on.

Example 4 — quarterly report on the first of January, April, July, October at 06:00.

0 6 1 1,4,7,10 *

Field 4, 1,4,7,10, is a comma list of individual months. Field 5 is *, so weekday is unrestricted. The next five runs are 01 January, 01 April, 01 July, 01 October, and 01 January of the following year, each at 06:00. The comma list stays sorted in the normalized output, and the parser confirms that 1,4,7,10 is exactly four months, not eight.

Example 5 — every ten minutes inside a custom minute window.

10-50/20 * * * *

This is a step on a range. Field 1 starts at 10, ends at 50, and steps by 20, which expands to 10, 30, and 50. Combined with * on every other field, the job fires at xx:10, xx:30, and xx:50 of every hour, every day, every month. The parser surfaces that expansion in the field summary so you do not have to do the arithmetic in your head, and it rejects the same step written as 50-10/20 because the range is descending.

Field Reference: Ranges, Lists, and Steps

Field	Valid range	Wildcard form	Syntax example	Normalized expansion
Minute	0–59	*	0,15,30,45	0,15,30,45
Hour	0–23	*	8-12	8,9,10,11,12
Day of month	1–31	*	1-31/10	1,11,21,31
Month	1–12	*	1,4,7,10	1,4,7,10
Day of week	0–7 (both 0 and 7 mean Sunday)	*	1-5	1,2,3,4,5

These ranges match the conventional Cronie-style crontab format described in the crontab(5) reference. Anything outside them, including negative numbers, descending ranges like 5-1, zero-step values like */0, or empty list items, is rejected with a focused error rather than silently coerced. Step expressions also require the divisor to be a positive integer, which is why */15 works and */0 does not.

Day-of-Month and Day-of-Week OR Behavior

The day fields require special attention. In traditional cron, when both day-of-month and day-of-week are restricted (neither is *), the schedule matches when either field matches — a documented OR rather than a strict AND. A rule like 0 9 21 * 1 fires on the 21st of every month and on every Monday, which means a Monday that is also the 21st produces one job, not two, because the minute and hour still have to match exactly once per minute.

When one day field is a wildcard, the restricted field fully controls matching. The Cron Parser follows this OR behavior because it matches what Cronie, Vixie cron, and most production schedulers actually do. If a scheduler uses a different rule — Quartz, for example, treats ? as an explicit "no value" and uses AND for both day fields — the same five-field string can produce a different schedule, which is one reason the parser output is labeled a verification aid rather than a deployment command.

Inputs the Cron Parser Rejects

The parser deliberately targets the portable numeric core of cron and refuses anything outside it. Common rejected inputs include:

Month or weekday names such as JAN or MON, since they vary between dialects.
Nicknames such as @daily or @hourly, which expand differently across cron implementations.
Six- or seven-field expressions used by Quartz or cloud schedulers, which add seconds or years.
Quartz question marks, last-day syntax like L, nth-weekday rules like 5#2, hashed schedules, and random ranges.
Extra command text after the five fields, since that belongs on the crontab line, not inside the schedule.
Descending ranges (5-1), zero or negative steps, empty list items, and values outside the field range.

Each rejection comes back with a focused error message that names the offending field. That feedback loop turns a typo into a fix instead of a silent miss in production, and it is also what makes the next-run calculation safe: the parser scans forward by whole minutes and stops if five matches cannot be found within five years, which prevents a malformed or extremely sparse input from locking the browser.

Verifying Against the Scheduler Before Deploying

Two practical checks make the difference between a parser that helps and one that misleads. First, confirm the time zone of the host or container that will run the job — UTC inside the parser is a calculation convenience, not a deployment directive. Second, confirm the day-of-month / day-of-week semantics and any extensions your scheduler supports, since the same five numeric fields can mean different things in Cronie, Quartz, Kubernetes CronJobs, systemd timers, or cloud schedulers. For a deeper review of syntax across environments, see the cron parser cheat sheet on ranges, steps, and examples.

The parser itself does not execute commands, contact a server, or save expressions, so treat its output as a verification aid. Always confirm the production scheduler's time zone, daylight-saving policy, day-field semantics, and supported extensions before deploying a critical backup, billing, notification, or maintenance job.