Developer tools · Crontab generator
Why cron has no seconds field, and where six-field expressions come from
· Background
cron dialects validation
A six-field expression is not a cron expression, even though it looks like one. This post explains why Unix cron stops at minutes, and how Quartz, Spring and cloud schedulers extended the grammar.
A six-field expression belongs to another scheduler style, not this parser
When ToolAcre sees six whitespace-separated parts, it refuses them and explains that its format has exactly five positions: minute, hour, day of month, month and day of week. The message notes that a leading seconds style appears in Quartz or systemd-like syntax. It does not silently drop the first token.
That refusal prevents positional corruption. Deleting a token without understanding the source grammar can shift every remaining value. Translation starts by identifying what each source field means and whether the intended schedule is representable in the five-field target.
The repository proves minute-first grammar, not the historical reason cron uses minutes
The implemented field array begins at minute and ends at weekday. No seconds or year specification exists. Tests require exact field count and reject both shorter and longer expressions. That is sufficient to document the current grammar.
The workbook offered a historical explanation based on a daemon waking once per minute. This repository does not contain the archival implementation needed to prove that origin. The article therefore says only that ToolAcre’s model has minute resolution and no seconds position.
Quartz details beyond a leading seconds style are not implemented here
The source error message names Quartz as an example of a seconds-first style, but the parser does not implement Quartz operators or optional positions. Characters such as `?`, `L`, `W` and `#` fail the ordinary value reader. They are not translated or explained as supported syntax.
Avoid using ToolAcre as a Quartz validator. A valid source expression may encode relationships that five-field cron cannot represent. Read source documentation, state the requirement in words and rebuild only the portion supported by the target grammar.
Spring and cloud scheduler grammars are outside the evidence set
Framework and cloud scheduler names in the workbook require their own current documentation. The repository has no Spring, EventBridge, Kubernetes or GitHub Actions schedule schema. Their field counts, aliases and time-zone policies should not be summarized from memory here.
Similarity is not compatibility. Two products can both call a string cron while assigning different positions or day semantics. ToolAcre’s strict five-field parser is valuable because it stops at its boundary instead of accepting an expression whose meaning it cannot preserve.
Worked example: reconstruct a representable quarter-hour weekday schedule
Suppose the source requirement is every fifteen minutes during hours 9 through 17 on weekdays, and no foreign operator carries additional meaning. In ToolAcre the representable form is `*/15 9-17 * * MON-FRI`. The parser expands quarter hours, inclusive hours and named weekdays.
The description and preview then expose the target interpretation, including a final daily candidate at 17:45. Compare that with the source scheduler’s actual behavior before calling the translation equivalent. The five-field form is correct only for the verbal requirement established during translation.
Sub-minute command loops are not generated or recommended
Sub-minute work cannot be expressed because minute is the smallest field. The workbook suggested a loop inside a command, but ToolAcre does not generate, execute or supervise loops. Such a pattern introduces timing, overlap and shutdown concerns outside its calendar model.
Choose a runtime designed for the required resolution and verify it there. Do not disguise a seconds requirement as five-field cron by placing seconds in the minute slot. The resulting schedule would be slower and semantically different despite passing numeric validation in some cases.
Foreign month-end operators remain untranslated
Month-end and ordinal-weekday operators from other grammars are also outside scope. Removing them can broaden or narrow dates unpredictably. ToolAcre supports ordinary values, names, ranges, lists and steps, plus its documented aliases; that set defines the translation ceiling.
When the requirement exceeds the ceiling, report “not representable” and retain a scheduler that supports it or redesign the action. A lossy rewrite that happens to parse is worse than a clear incompatibility because it creates plausible but incorrect future dates.
Takeaway: count the fields before you paste — and use the generator to build the five-field version that crontab accepts
Count fields first, identify the source dialect second and translate the requirement—not the punctuation—third. ToolAcre’s error makes the first step unavoidable and its description provides a target-side check after reconstruction.
The route generates five-field expressions only. It does not validate seconds, years or scheduler-specific operators, and it does not schedule a job. Those omissions define a reliable boundary that should remain visible in every migration discussion.