Developer utilities

Small developer utilities with sharp contracts

Day-to-day engineering still depends on two deceptively small languages: semantic version strings that order releases, and cron expressions that schedule jobs. Both appear in CI configs, container tags, package manifests, and orchestrators. Mistakes are cheap to type and expensive to debug—an off-by-one in precedence or a wrong day-of-week field can ship the wrong artifact or skip a nightly task.

This hub groups browser-side helpers for those contracts. Try Semver compare when you need a clear precedence result between two versions; use Cron parser when you need a five-field schedule decoded into human-readable timing; use Chmod calculator for permission modes; and HTTP status lookup for response codes.

Subtools in this family

• Semver compare — compare two semantic-version strings and report their relative order (and equality) under SemVer rules.
• Cron parser — interpret a standard five-field cron expression (minute hour day-of-month month day-of-week) into an understandable schedule description.
• Chmod calculator — convert Unix permission modes between symbolic (rwxr-xr-x) and octal (755) forms.
• HTTP status lookup — map an HTTP status code to its reason phrase and a short explanation.

They are intentionally narrow. Neither deploys jobs nor publishes packages; both reduce ambiguity when reading or writing the strings your tools already consume.

Semantic Versioning in practice

SemVer versions look like MAJOR.MINOR.PATCH with optional pre-release and build metadata: 1.4.2, 2.0.0-rc.1, 1.0.0+build.7. Precedence rules matter:

1. Compare major, minor, and patch numerically.
2. A pre-release version (-rc.1) has lower precedence than the same version without a pre-release (1.0.0-rc.1 < 1.0.0).
3. Pre-release identifiers compare either numerically or lexically depending on whether they are digit-only.
4. Build metadata (+...) does not affect precedence; 1.0.0+aaa and 1.0.0+bbb are equal in order.

String sorting is not SemVer sorting. Lexicographic order puts 1.10.0 before 1.2.0 as text, which is wrong numerically. Always compare with a SemVer-aware algorithm—exactly what Semver compare is for—before writing upgrade gates or changelog buckets.

Where version comparison shows up

• Dependency ranges in package managers resolve against SemVer precedence (with each ecosystem’s range syntax on top).
• Migration code often branches on if (version < 2.0.0).
• Container tags may mix SemVer with moving tags (latest); compare immutable SemVer tags, not mutable aliases.
• Feature flags sometimes key off minimum client versions advertised in headers.

When comparing, normalize inputs: trim whitespace, reject incomplete 1.2 if your policy requires a patch component, and decide how to treat v1.2.3 prefixes (many libraries strip a leading v). Document that policy in your repo so CI and humans agree.

Cron expressions (five-field)

Classic Unix cron uses five fields:

Special characters include * (any), , (list), - (range), and / (step). Some schedulers add a sixth seconds field or a seventh year field; others use @daily macros. This family’s parser targets the standard five-field shape—confirm your orchestrator’s dialect before trusting a schedule in production.

Day-of-month versus day-of-week

Cron’s most confusing rule is the interaction of day-of-month and day-of-week when both are not *. On traditional Vixie cron, the job runs when either field matches (OR), not when both match (AND). Different products (systemd timers, Kubernetes CronJob, cloud schedulers) document their own interpretation. Always verify against the platform that will execute the job—not only against a generic explanation.

Time zones are another trap: cron daemons usually use the host’s local zone or an explicit CRON_TZ. A schedule that looks “3:00” in UTC is a different civil time in Europe/Rome. Parsers that describe fields do not by themselves apply DST rules; you still choose the clock your runner uses.

Practical workflows

• Paste candidate release tags into Semver compare before approving a rollback (“is 1.9.10 actually newer than 1.10.0-rc.2?”).
• Decode a schedule from a YAML snippet with Cron parser during incident review when a job “didn’t fire.”
• Keep a short table of approved cron patterns in team docs; use the parser to explain them to newcomers without running the job.

Common mistakes

SemVer

• Treating hyphenated marketing versions (2024.05.01) as SemVer without checking the scheme.
• Ignoring pre-release precedence when promoting rc builds.
• Sorting versions as strings in spreadsheets.

Cron

• Confusing five-field with quartz-style six/seven-field expressions.
• Assuming day-of-month AND day-of-week.
• Forgetting that */2 in the hour field means every 2 hours from 0, not “twice a day” in the abstract.
• Testing only in one time zone.

Limitations

These utilities do not install cron entries, call package registries, resolve npm/cargo/pip ranges, or simulate calendar runs across DST transitions year-wide. SemVer compare does not evaluate caret/tilde ranges (^1.2.3); it compares concrete versions. Cron parse does not guarantee behavioral identity with every scheduler dialect.

Related tooling

Release metadata sometimes appears inside JSON manifests—validate those with Valid JSON. If you generate site crawl rules for deployed apps, see the robots.txt generator. For LLM-assisted CI copy or changelog drafting budgets, Estimate LLM tokens sits in the AI utilities family.