Developer tools · Crontab generator
crontab(5) fields: what POSIX specifies and what is a Vixie extension
· Background
cron portability validation
Not every cron feature is standard. This post separates what the POSIX crontab specification requires from the extensions (steps, names, nicknames) that Vixie cron added and most Linux systems assume.
A valid ToolAcre expression can still be unsupported by another scheduler
A schedule that passes ToolAcre has satisfied this parser, not every cron implementation. Portability begins with that modest statement. The route accepts exactly five fields and a defined token grammar. A target appliance, service or framework may accept less, more or something structurally different.
Keep the browser result as one piece of evidence: expression, description, warnings and preview zone. Before deployment, compare the target documentation and run a harmless test. Validation becomes dangerous only when a local green signal is promoted into a universal compatibility guarantee.
The repository does not establish what POSIX requires
The workbook separated POSIX requirements from extensions, but no POSIX specification appears in the repository sources. ToolAcre’s behavior cannot prove which features a standard mandates. This section therefore describes implemented syntax without assigning it to a standards body.
Implemented numeric ranges are 0–59 minutes, 0–23 hours, 1–31 days of month, 1–12 months and 0–7 weekdays. Wildcards, single values, inclusive ranges, comma lists, wildcard steps, range steps and a bare starting value with a step are all parsed and tested.
Names, steps, Sunday 7 and aliases are implemented here without a standards-history claim
Month names JAN through DEC and weekday names SUN through SAT are case-insensitive. Names can appear alone, in lists and in ranges. Weekday 7 is accepted as Sunday and normalized to 0. Those are observable properties of `parseField`, regardless of how another implementation classifies them.
The alias table expands `@yearly`, `@annually`, `@monthly`, `@weekly`, `@daily`, `@midnight` and `@hourly`. `@reboot` is deliberately refused because it has no calendar schedule to preview. Unknown at-sign words receive an error naming the supported list.
Environment assignment support is outside this parser
Environment assignments are not part of this expression grammar. The input box expects one schedule, and `parseCron` splits it into five pieces after resolving a supported alias. A `KEY=value` line cannot be tested for expansion, quoting or portability through this route.
That omission prevents a false standards claim. A complete crontab file can contain constructs that an expression-only tool never sees. Check those separately against the target. ToolAcre’s precise field errors should not be repurposed as judgments about unrelated lines in a larger file.
Check the target grammar and use a harmless schedule test
Target checking should start with field count and operators. Confirm whether names, Sunday 7, slash steps and at-sign aliases are accepted. Then install a harmless observable action for a near-term time, remove it after evidence is captured and compare the target result with the intended expression.
Do not test portability with a sensitive command or by waiting for a rare annual date. Choose the smallest safe probe that distinguishes grammar support. ToolAcre can help construct that schedule and explain it, while the target run establishes the part the browser cannot know.
Worked example: step form and explicit list under ToolAcre’s grammar
For every five minutes, ToolAcre accepts `*/5 * * * *`. It also accepts the explicit minute list `0,5,10,15,20,25,30,35,40,45,50,55 * * * *`. Parsing expands both minute fields to the same twelve values, so their next-run candidates match under the same starting instant and zone.
The explicit list can serve as a fallback candidate when a target lacks step syntax, but this repository cannot certify that target’s list support. Compare both forms in ToolAcre for semantic equivalence, then verify whichever form the destination documents. Equivalence here is not portability proof there.
Six-field syntax is rejected; its external semantics are not documented here
A sixth field is not accepted. The error suggests that a leading seconds style belongs to Quartz or systemd-like input, but the parser does not implement those grammars. It has no year field and no `?`, `L`, `W` or `#` operators.
Count fields before attempting translation. If unsupported syntax carries scheduling meaning, an apparent five-field rewrite may be lossy. Use documentation and tests for the source scheduler, then express only requirements representable by ToolAcre’s target grammar. Anything else should remain an explicit incompatibility.
Takeaway: know which features are extensions — and use the generator to build and check both forms when portability matters
Portability is a comparison, not a label embedded in an expression. ToolAcre gives one well-tested side: five positions, numeric boundaries, selected names, composable ranges/lists/steps and seven aliases. It also gives clear refusals for malformed or foreign forms.
Use that contract to reason precisely, then verify the other side. An explicit list and a step can be equal in this parser while only one works elsewhere. Reporting the dialect boundary is more actionable than invoking a standard the article has not actually sourced.