Skip to main content

Code 4

Regex, SQL formatting, cron parsing and diff

Expressions that are easy to write and hard to read: cron schedules, regular expressions, SQL that arrived as a single line. These tools turn them back into something you can check.

// Tools in this category

// The cost of a misread expression

A cron field that you read as "every five minutes" but that actually means "at five past every hour" will not fail loudly. It will quietly run 12 times less often than you expected, and you may not notice for weeks. The same is true of a regex that looks right and silently fails on one input class. Checking the expression against a tool that expands it into concrete run times or concrete matches is usually faster than reasoning it through.

// Watch the time zone

Cron run times are computed in the time zone of the machine you are on. The host that actually runs the job has its own, and containers and cloud runners default to UTC, so 09:00 in a crontab on a UTC host is not 09:00 for a team in Tokyo or Berlin. When a schedule matters to people rather than to machines, translate it with the Time Zone Converter before you commit it.

// What to reach for

The Cron Expression Parser accepts standard five-field expressions, explains each field in plain English and lists the next run times. The Regex Tester highlights matches in place and lists capture groups. The SQL Formatter turns a logged one-liner back into something readable. The Diff Checker compares two texts by line or by character.

// Code: frequently asked questions

Which cron dialect is supported?
The standard five-field format used by Linux crontab. Extensions such as the seconds field used by Quartz and the @reboot style shorthands are not expanded.
Do the predicted run times account for daylight saving?
Run times are computed in your browser local time zone, so they follow that zone daylight saving rules. If the job runs on a UTC host, read the times as a pattern rather than as wall-clock times for your users.

// Other categories