Convert AWS EventBridge to Quartz
Translate EventBridge cron() and rate() expressions to Quartz scheduler format: seconds field added, year field dropped, shared calendar tokens, rate() approximations.
About this conversion
Bringing an EventBridge schedule into a Quartz-based service (Java, Spring) keeps the parts that usually hurt — day numbering and calendar tokens — completely intact, because both dialects count Sunday as 1 and both speak L/W/#. What changes is the frame: the cron( … ) wrapper comes off, a seconds field (0) is prepended, and the year field disappears. That last one is the trap in this direction — this converter emits Quartz's common 6-field form, which ends at day-of-week, so a year-constrained EventBridge rule loses its year on the way over. Quartz's optional 7-field variant can carry a year; if your scheduler accepts it, re-append the year by hand after converting.
What changes in this conversion
- The cron( … ) wrapper is removed, a seconds field (0) is prepended, and the year field is dropped — 6 fields in, 6 fields out, but not the same six.
- Day-of-week numbering is identical (Sunday = 1) — no numeric shifting in either direction.
- L, W and # calendar tokens pass through verbatim; both dialects share them.
- rate(…) expressions are synthesized into cron fields, with rolling-interval caveats for anything above one minute.
Worked examples
cron(30 9 ? * MON-FRI *)converts to0 30 9 ? * MON-FRIlosslesscron(0 8 ? * 2#1 *)converts to0 0 8 ? * 2#1losslesscron(0 12 * * ? 2027)converts to0 0 12 * * ?lossy- ⚠ This converter's 6-field Quartz form has no year position — the year constraint (2027) is dropped. Quartz itself allows an optional 7th year field; re-append it if your scheduler accepts 7-field expressions.
rate(2 hours)converts to0 0 */2 * * ?lossy- ⚠ rate() is a rolling interval from the rule's start time; the cron form fires on the hour instead.
Every converted expression above is produced by the same conversion engine the tool uses — generated and integrity-tested, not hand-written.
Lossy and refused conversions
A real year constraint is the main loss: the 6-field Quartz form this converter emits has no year position, so cron(0 12 * * ? 2027) becomes a daily-at-noon trigger that fires every year, flagged accordingly (Quartz's optional 7th field could hold that year — re-append it if your scheduler parses 7-field expressions). rate() expressions carry the standard rolling-versus-clock-boundary caveat — rate(2 hours) counts 120 minutes from rule creation, while the converted trigger fires every other hour on the clock. Where EventBridge jobs implicitly ran in UTC, a Quartz trigger fires in whatever timezone its scheduler is configured for — the expression converts, the operational context doesn't.
FAQ
Where did my year constraint go?
This converter emits Quartz's common 6-field form (seconds through day-of-week), which has no year position, so the constraint is dropped and the conversion flagged. Quartz itself allows an optional 7th year field — if your scheduler accepts 7-field expressions, re-append the year by hand; otherwise guard on the year inside the job.
Will my 2#1 (first Monday) schedule survive?
Yes, verbatim. Quartz and EventBridge share the # token and the Sunday=1 numbering, so nth-weekday schedules move between them without translation.