Sume scheduled run across daylight saving: Monday 9am New York

Does a Sume schedule fire at the right local time after the clocks change?

A Sume schedule stores a cron expression and an IANA timezone, and Sume's cron code uses the cron-parser library (version 4.9.0). The expression is read in the zone you chose, so 0 9 * * 1 with America/New_York means 9:00 on the wall clock in New York, whatever UTC offset applies that week.

We checked this with that library rather than assuming it. The next Mondays after the 2026 fall change come out as 13:00 UTC on October 26, which is 9:00 EDT, and 14:00 UTC on November 2, which is 9:00 EST. The local time stays put and the UTC time moves.

What happens to a time that is skipped or repeated?

A daily job at 2:30 does not exist on the spring-forward night, and a job at 1:30 happens twice on the fall-back night. Run through the same library, 30 2 * * * in America/New_York produced 07:30 UTC on March 7, 2026, then 07:30 UTC on March 8 (3:30 EDT, shifted but fired once), then 06:30 UTC on March 9. 30 1 * * * produced 05:30 UTC on October 31 and on November 1 (the first 1:30 EDT, fired once), then 06:30 UTC on November 2.

So neither a skipped nor a repeated hour double-fires or drops a day in this setup. If a run on an in-between night matters to you, schedule outside the 1:00 to 3:00 window and avoid the question.

What should I check when I set one up?

Name the zone explicitly, because a UTC schedule will drift an hour against local publishing times twice a year. A zone without daylight saving, such as Asia/Seoul, never moves.

• Pick an IANA name such as America/New_York, not an abbreviation like EST.
• Keep the default spend cap in mind: a scheduled action defaults to $1.00.
• on_active_run defaults to skip, so a slow run makes the next slot skip instead of stacking.
• The trigger type is fixed when the action is created, so choose cron or API trigger up front.