Cron Dialect Converter

Convert a cron expression between the four dialects that actually differ: Unix crontab, Quartz, Spring, and AWS EventBridge. It remaps the day-of-week numbering (Unix 0–6 Sun=0 vs Quartz/AWS 1–7 Sun=1), adds or drops the seconds and year fields as the target requires, applies the ? rule where it is mandatory, and warns you whenever a token like L or # can't be represented in the target. It runs entirely in your browser.

How to use the Cron Dialect Converter

Pick the dialect you're converting from and the one you want to, then enter the source expression. The converter parses it according to the source dialect's field layout, normalizes the parts, and re-emits them in the target's layout — handling the three things that differ between dialects automatically: the presence of a seconds field (Quartz and Spring have one; Unix and AWS do not), the optional year field (Quartz and AWS), and the day-of-week base (Unix and Spring count from 0 with Sunday = 0; Quartz and AWS count from 1 with Sunday = 1).

Read the Notes panel carefully when it appears. Some conversions lose information or can't be expressed exactly: a seconds value other than zero is dropped when targeting a dialect without seconds; the calendar specials L, W and # are kept verbatim but won't parse in Unix or Spring cron; and a rule that constrains both day-of-month and day-of-week can't be carried into a dialect that mandates ?. The converted expression is always shown so you can copy it, but treat any note as a prompt to double-check the result against your scheduler's documentation.

Why cron dialects are not interchangeable

"Cron syntax" is not one format. The five-field Unix crontab dialect (minute, hour, day-of-month, month, day-of-week) is the oldest and simplest, but the popular schedulers built on top of it each changed the grammar in incompatible ways. Copying an expression from a Stack Overflow answer into the wrong system is a common cause of jobs that run at the wrong time — or fail to register at all.

The differences cluster around four points. Field count: Quartz and Spring prepend a seconds field, and Quartz and AWS append an optional year, so the same schedule can be five, six, or seven tokens long. Day-of-week numbering: Unix and Spring use 0–6 with Sunday as 0 (and accept 7 as Sunday too), while Quartz and AWS use 1–7 with Sunday as 1 — an off-by-one that quietly shifts a "Monday" job to Sunday if ignored. The "?" character: Quartz and AWS require exactly one of day-of-month and day-of-week to be ?, whereas Unix and Spring have no such rule and use * instead. Calendar specials: Quartz and AWS support L (last), W (nearest weekday) and # (nth weekday); Unix and Spring do not.

This converter encodes those rules as a small model of each dialect and translates between them mechanically. It maps weekday numbers through a canonical Sunday-based representation so the base offset is corrected, inserts a zero seconds field or a wildcard year when the target needs one, drops fields the target lacks, and rewrites */? in the day fields to satisfy the target's constraints. Where a faithful translation is impossible — an L token going to Unix, or a both-days-constrained rule going to Quartz — it emits the best available expression and a clear warning rather than failing silently, because a wrong-but-plausible cron line is more dangerous than an obvious error.

Common use cases

  • Moving jobs to a new platform. Port a crontab schedule to AWS EventBridge or a Quartz-based service without re-deriving it by hand.
  • Fixing the weekday off-by-one. Convert between 0-based and 1-based day-of-week dialects so "weekdays" stays weekdays.
  • Spring to crontab. Strip the seconds field when copying a Spring schedule into a system crontab.
  • Sanity-checking a migration. See exactly which tokens survive a conversion and which need manual attention.

Frequently asked questions

Which dialects does this convert between?
Four: Unix/crontab (5 fields, 0-based weekday), Quartz (6-7 fields with seconds and optional year, 1-based weekday, ? rule), Spring (6 fields with seconds, 0-based weekday), and AWS EventBridge (6 fields with year, 1-based weekday, ? rule). These are the dialects whose grammars genuinely differ; tools like Jenkins or Kubernetes CronJobs use the plain Unix form.

How is the day-of-week field remapped?
Each weekday is converted through a canonical representation where Sunday = 0, then re-expressed in the target base. Unix and Spring use 0-6 (Sunday 0); Quartz and AWS use 1-7 (Sunday 1). Ranges, lists, steps, and the # and L operators have their numeric parts remapped while names like MON and operators are preserved.

What happens to the seconds field when I target Unix cron?
Unix and AWS have no seconds field, so it is removed. If the source seconds value was something other than 0, a note tells you the precision was lost — the converted job will run at second 0 of the matching minute rather than the original second.

Can it convert L, W and # specials?
Only into dialects that support them (Quartz and AWS). When the target is Unix or Spring, those tokens are passed through unchanged but flagged with a warning, because standard cron parsers will reject them. There is no exact equivalent, so the rule must be reworked manually for those targets.

Why did my both-days rule turn into a "?"
Quartz and AWS forbid constraining day-of-month and day-of-week at the same time. If your source (from a dialect that allows it) set both, the converter has to pick one and sets the other to "?", with a warning. Verify the result matches your intent — you may need to split it into two scheduled rules.
Embed this tool on your site

Free to embed, no attribution required (but appreciated). Paste this where you want the tool to appear: