Quartz cron, converted to a crontab line.
Quartz, Spring and node-cron expressions start with a seconds field. A Linux crontab has five fields and no seconds at all. Paste one here and get the standard line, with every difference written out instead of silently dropped.
Quartz and 6-field cron converter
Try one
The three formats, side by side.
The extra field is the easy part. The day-of-week numbering and the ? token cause most
of the broken schedules, because they look harmless and mean something different.
| Format | Fields, in order | What is different |
|---|---|---|
| Quartz (Java) | sec · min · hour · day · month · weekday · year? | The year field is optional. ? means “no specific value”, Sunday is 1, and L, W and # exist. |
| Spring, node-cron | sec · min · hour · day · month · weekday | Six fields like Quartz, but the day-of-week numbers follow Unix: Sunday is 0. |
| Standard crontab | min · hour · day · month · weekday | Five fields, no seconds, no year. * covers “any”, Sunday is 0, names are allowed. |
What cannot be converted, and why.
A converter that guesses here is worse than one that refuses: a crontab that fails to parse runs nothing at all, and you find out from the missing report rather than from an error.
| What you wrote | What a crontab does |
|---|---|
| seconds ≠ 0, or every second | A crontab fires once per matching minute, at second 0. You get the closest five-field line and it is marked not exact rather than quietly rescheduled. |
| L, W, #, H | Quartz and some commercial schedulers understand these; a standard crontab answers with a parse error and runs nothing, so the converter refuses rather than guessing. Where a portable near-miss exists (L becomes 28-31) it is offered with the trap named. |
| a year field | A seven-field expression can name a year, a crontab cannot. Move the check inside the job, or keep a scheduler that understands it. |
| a numeric weekday | Quartz counts Sunday as 1, a crontab counts it as 0, so a number copied by hand lands on the wrong day. The dialect switch applies the right numbering; MON-FRI avoids the question. |
| day of month and day of week together | Quartz needs a ? in one of them and combines the other. Standard cron fires when either one matches, so a line that restricts both runs on more days than the original. |
Converted examples, with the reasoning.
| Quartz or 6-field | Standard crontab | What changes |
|---|---|---|
| 0 0 12 * * ? | 0 12 * * * | Exact. Seconds are 0 and the only other change is ? becoming *, which means the same thing here. |
| 0 0/15 9-17 * * MON-FRI | */15 9-17 * * MON-FRI | Exact. Quartz writes “start at 0, then every 15” as 0/15; the standard form writes the same thing as */15. |
| 0 30 8 ? * MON-FRI | 30 8 * * MON-FRI | Exact. Named days travel unchanged, and ? only had to become *. |
| 0 0 0 L * ? | 0 0 28-31 * * | Closest, not exact. A crontab has no L. 28-31 runs on the last day of every month, but also on the 28th, 29th and 30th of a long one, so the job needs a guard that checks whether tomorrow is the 1st. |
| 0 0 12 ? * 2#1 | — | No equivalent. The # token asks for the first Monday of the month. Nothing in a five-field expression can say that, so no conversion is offered. |
The other way round is covered too: the parser reads any five-field expression back field by field, and the schedule pages explain the ones people search for most.
Quartz cron questions, answered.
How do I convert a Quartz cron expression to a crontab line?
Three things change. Drop the seconds field first, because a crontab has none. Replace ? with *: Quartz uses ? to mean 'no specific value', while standard cron uses * for 'any'. Then check the day-of-week numbers, because Quartz counts Sunday as 1 and crontab counts it as 0. The converter above does all three and lists what it could not carry over.
Why does Quartz use six fields?
Quartz starts with a seconds field, so 0 0 12 * * ? means 12:00:00 rather than 12:00. It also allows an optional seventh field for the year, and adds L, W and # tokens for the last day of the month, the nearest weekday and the nth weekday. Spring and the Node schedulers borrowed the six-field shape, while a Linux crontab kept the original five.
What happens to the seconds field?
A standard cron expression fires once per matching minute, at second 0. If your expression asks for second 0 the conversion is exact. If it asks for another second, or every second, the standard form cannot express it: the converter still gives you the closest five-field line and marks it as not exact rather than quietly changing your schedule.
Does Linux cron support L, W and #?
No. Those belong to Quartz and to some commercial schedulers. The Vixie cron that ships with Linux answers such a line with a parse error and runs nothing, which is worse than a refusal. For the last day of the month the portable trick is 28-31 with a guard inside the job, which is what this converter offers for L.
Is a six-field expression always Quartz?
No. Spring, node-cron and some cloud providers also take six fields, but their day-of-week numbers follow Unix, where Sunday is 0. Quartz numbers Sunday as 1. The dialect switch above the field decides which numbering is applied, and named days such as MON-FRI avoid the question entirely.