The usual way to sanity-check a scheduled job against daylight saving is to look up when the clocks change this year and eyeball whether the job's time is anywhere near it. That catches the one obvious case — a job at 02:30 the week 02:00 jumps to 03:00 — and stops there. A calendar has no way to walk a real cron expression forward, tell a skip apart from an overlap, or notice a failure mode that never touches a transition date at all.
Checking a DST calendar is free and requires no tool: look up the transition date for your timezone, compare it to the job's time by eye. It works for the single case where the schedule's time obviously coincides with the transition hour on an obviously-matching date.
This checker uses the same IANA timezone database a calendar lookup is based on, but walks your actual cron expression forward occurrence by occurrence, resolving each local time against the real transition instants rather than comparing dates by eye. It also runs a second, unrelated check a calendar cannot express at all: whether a fixed-UTC-only scheduler holds your intended local time steady across the year.
| Question | Where to answer it |
|---|---|
| Does clocks-change week obviously overlap my job's time? | Either one. A calendar lookup answers this at a glance, and so does this checker. |
| Does a schedule with a step, list, or day-of-month/day-of-week combination actually land on the transition date? | This checker. Working that out by eye means correctly applying cron's OR rule for restricted day fields, which is the single most common cron misreading. |
| Is a fall-back occurrence a skip to shrug off, or does it happen twice? | This checker, which reports both real UTC instants for an ambiguous occurrence — not visible from a calendar at all. |
Does my GitHub Actions schedule: cron drift against the local time I meant? | This checker's separate drift check. A DST calendar has nothing to say here, because nothing is skipped or doubled — the job just runs an hour early or late for months. |
| Is anything I enter uploaded anywhere? | Neither. A calendar lookup involves no tool at all, and this checker runs entirely in your browser. |
It catches the case where the cron time and the transition hour are the same, like a 02:30 job the week clocks jump from 02:00 to 03:00. It does not catch a cron expression with a step or a list in the hour or minute field, or a day-of-month/day-of-week combination, because working out which of the resulting occurrences actually lands on the transition date requires walking the schedule forward, not reading a calendar.
Two things this checker reports separately. First, a fall-back occurrence is not a skip to notice and move past — the local time genuinely happens twice, at two different UTC instants, and a calendar has no way to show you both. Second, a fixed-UTC-only scheduler (GitHub Actions' schedule: cron among them) never touches a gap or an overlap at all; it just runs an hour early or late for half the year, which does not look like a DST bug from the calendar's point of view because nothing is skipped or doubled.
Because the standard cron day-matching rule is easy to misread by hand: when both day-of-month and day-of-week are restricted (neither is a wildcard), a date matches if it satisfies either field, not both. A schedule that looks like it only runs on specific dates can also fire on every matching weekday, which changes whether it actually lands on a transition date at all.
No, and it does not try to. It uses the same IANA timezone database your browser already ships to find the transitions itself, then walks your actual cron expression forward against them and reports which specific occurrences are affected. The transition dates are an input this tool computes for you, not something you need to already know.
There is nothing to upload either way — checking a calendar involves no tool at all, and this checker runs entirely in your browser using the Intl timezone database it already ships. The CLI makes no network call either.