A cron parser is a validator and interpreter for classic five-field cron expressions: minute, hour, day of month, month, and day of week. Cron expressions are compact, but that compactness can conceal a misplaced field or a day rule that behaves differently from an ordinary calendar filter. The Cron Parser checks that the expression contains exactly five fields, validates each field, and turns the compact notation into a normalized expression and a field-by-field summary. It accepts numeric values, the asterisk wildcard, comma-separated lists, inclusive ranges, and positive steps on a wildcard or range. After validation, it calculates the next five matching instants and presents them in the browser's local time alongside ISO UTC timestamps. That makes the tool useful for checking a schedule before copying it into a crontab file or another scheduling service, while keeping an important distinction clear: a validated expression does not prove that every scheduler interprets the same syntax, day rules, or time zone in the same way.
The five fields, in order
Read a classic cron expression from left to right. Every position controls one part of the calendar, so moving a value into the wrong field can change an hourly task into a daily one. Cron Parser checks each value against the conventional range used by Cronie-style crontab files:
| Field | Range | What it selects |
|---|---|---|
| Minute | 0-59 | The minute within each hour |
| Hour | 0-23 | The hour of each day |
| Day of month | 1-31 | The numbered day within a month |
| Month | 1-12 | The numbered calendar month |
| Day of week | 0-7 | The weekday; both 0 and 7 represent Sunday |
The expression must contain exactly five space-separated fields. Extra command text is rejected because this parser checks the schedule expression rather than a complete crontab line. Calendar validity is handled with JavaScript Date: a day-31 rule naturally skips months without a 31st, and February rules respect leap years.
Validate and explain a schedule
Use the parser as a field-by-field check rather than a single pass-or-fail test. The workflow covers the complete expression and the assumptions that determine when it will run.
- Enter exactly five fields. Place the minute, hour, day-of-month, month, and day-of-week values in that order. Do not add a seconds field, year field, command, or other trailing content.
- Use supported numeric syntax in each field. Enter a number, an asterisk wildcard, a comma-separated list, an inclusive numeric range, or a positive step on a wildcard or range. Lists may combine individual values with ranges.
- Read all three forms of output. Review the normalized expression, the summary of what every field selects, and the next five matching times in local time and UTC. The summary explains the rule, while the run preview shows how often it will actually match.
- Confirm the execution environment. Compare the result with the documentation and configured time zone of the scheduler that will execute the job. Also check its daylight-saving policy and day-field behavior before deployment.
Interpret the normalized expression and run preview
Normalization makes the expression easier to inspect by removing extra spacing and changing weekday 7 to Sunday's value 0. The field summary then translates each position into selected values, and the preview supplies the next five matching date-time instants. Consider this complete schedule:
15 8-12/2 * * 1-5
- The minute field selects minute 15.
- The hour range and step select hours 8, 10, and 12.
- The day-of-month and month fields are wildcards.
- The day-of-week range selects Monday through Friday.
Because day of month is a wildcard, the restricted weekday field controls matching. The summary therefore describes matches at 08:15, 10:15, and 12:15 on weekdays. The run preview lists the next five matching date-time instants, shown in the browser's local time and as ISO UTC timestamps for comparison across systems. Candidate minutes are scanned forward by whole minutes, and calendar dates are resolved according to the actual length of each month.
Why the two day fields need special attention
Traditional cron uses an OR rule when both day fields are restricted. If day of month is restricted to the 21st and day of week is restricted to Monday, a matching time can occur on every Monday as well as on the 21st. The schedule does not require both day fields to match at once. The minute, hour, and month fields still have to match normally.
When one day field is a wildcard, the restricted field controls the match. A wildcard day of month combined with Monday through Friday therefore behaves as a weekday filter. This differs from the AND relationship people often expect from an ordinary multi-condition calendar rule.
Cron Parser follows the documented traditional OR behavior. It also applies this rule consistently while calculating upcoming times. A production scheduler can define related extensions or differences, so confirm its documentation rather than assuming that every environment follows the same day semantics.
How local time, UTC, and daylight-saving time are represented
The next-run engine enumerates candidate minutes as UTC instants and then formats those results for the viewer. Using UTC internally makes the calculation deterministic and avoids daylight-saving jumps inside the scan. The output provides two views of the same upcoming instants: browser-local time for human readability and ISO UTC timestamps for system comparison.
The browser's time zone is not the scheduler's time zone. The parser neither configures a production scheduler nor changes its behavior, so the displayed local times may not be the times at which the deployed job runs. Compare both columns with the scheduler's settings. If a schedule crosses a daylight-saving transition, the scheduler's own policy determines how affected wall-clock times are handled.
Supported syntax and deliberate boundaries
Cron Parser targets the portable numeric core of classic crontab syntax. Its accepted and rejected forms are explicit:
| Construct | Status | Details |
|---|---|---|
| Numeric value | Accepted | Must fall within its field's conventional range |
| Asterisk wildcard | Accepted | Selects every value available in that field |
| Comma-separated list | Accepted | May combine individual values and ranges |
| Inclusive numeric range | Accepted | Includes both the starting and ending values |
| Positive step | Accepted | Must be applied to a wildcard or an inclusive range |
| Names such as JAN or MON | Not accepted | Month and weekday values must be numeric |
| Nicknames such as @daily | Not accepted | Enter a five-field expression instead |
| Seconds or year fields | Not accepted | The supported format contains exactly five fields |
| Quartz question marks, last-day syntax, hashed schedules, random ranges, and vendor macros | Not accepted | These belong to other cron dialects or extensions |
Descending ranges, zero steps, empty list items, and values outside the applicable field range are rejected with a focused error. An expression with anything other than five fields is also rejected, including extra command text. This narrow scope avoids presenting unsupported dialect features as portable cron behavior.
That distinction matters because Cronie, Vixie cron, systemd timers, Kubernetes, Quartz, cloud schedulers, and CI services do not all accept the same fields or extensions. A five-field expression placed into a service that expects six or seven fields can mean something entirely different or be rejected. Always follow the exact scheduler documentation for the deployment environment.
Confirm the behavior in the scheduler that will execute it
Traditional cron references such as the Cronie crontab(5) source and the Oracle Linux cron guide can help establish the classic rules. They do not replace the documentation for the service that will run your job.
- Confirm that the destination expects a classic numeric five-field expression and does not require seconds, a year, aliases, or vendor extensions.
- Verify the scheduler's configured time zone and its policy for daylight-saving transitions.
- Confirm that the scheduler uses the traditional OR relationship when both day fields are restricted.
- Review the five upcoming matches for the expected frequency. The calculation stops if it cannot find five matches within a five-year scan bound, so an extremely sparse rule may not produce a full preview.
- Use the parser as a verification aid for critical backup, billing, notification, or maintenance jobs. It does not execute commands, contact a server, or save expressions.