Check your scheduled automation before the clock falls back

Start with the repeated hour

In U.S. locations that observe daylight saving time, clocks move back from 2 a.m. to 1 a.m. on November 1, 2026, according to NIST.[1] Before an app generates its next daily report or reminder, check what “once a day” means. This article uses a hypothetical New York store report to propose a practical review. It describes neither a customer incident nor measured savings. The useful deliverable is a small schedule contract that operations staff can understand and engineering can test.

Passing a bill is not the same as changing the law

As of October 30, 2026, the existing Uniform Time Act framework still applies. For locations observing daylight saving time, 15 U.S.C. §260a specifies 2 a.m. on the second Sunday in March through 2 a.m. on the first Sunday in November. These dates came from the 2005 amendment, effective March 1, 2007.[4] DOT explains that states may opt out of daylight saving time by law, but cannot independently adopt permanent daylight saving time.[5]

The passage news has a real basis: the House passed H.R.139, the Sunshine Protection Act, on July 14, 2026. However, the Senate committee’s official page lists July 16 referral to committee as the latest action—not enactment.[6][7] A House vote date is not an effective date for a new time regime. NIST’s current notice still specifies a one-hour fall-back at 2 a.m. on November 1, 2026.[8] Before changing automation for any future law, check both the enactment record and its effective-date provisions.

Separate local time from elapsed time

“Every morning at eight in New York” and “every twenty-four hours” describe different business needs. Ask the owner which one matters. For a store-opening report, record the named time zone, such as America/New_York, alongside the local time. For an interval-driven check, record the elapsed-time requirement. A fixed UTC schedule does not preserve the same local opening time throughout the year. Do not let the server location, a staff member’s laptop setting, or an AI assistant’s interpretation silently choose the rule.

Check the scheduler you actually use

AWS documents that EventBridge Scheduler does not repeat the scheduled invocation during fall-back, skips a cron occurrence at a nonexistent spring-forward time, and treats a rate expressed in days as twenty-four-hour durations.[2] Google Cloud Scheduler warns that wall-clock scheduling can produce execution anomalies around daylight-saving changes.[3] These are product-specific statements, not a universal cron rule. Record the actual service and configuration. Ask a vendor for its documented behavior if the app hides its scheduler. An unknown answer belongs in the review, not in a reassuring assumption.

Give the business run its own identity

For a report that should exist once per business date, we recommend a run identity built from store, report type, and business date. Claim that identity atomically before generation. If both repeated-hour occurrences reach the application, they should check the same business run. This is an editorial design recommendation, not a guarantee supplied by a clock setting. An hourly workflow needs a different identity because both hours may represent legitimate work. Define the reporting day’s cutoff explicitly when a store operates after midnight.

Keep two coordinates in the record

Retain the intended occurrence, actual UTC timestamp, named local zone and offset, business date, outcome, and external receipt. In the New York example, the two local 1:30 a.m. occurrences correspond to 05:30 and 06:30 UTC. A display containing only “01:30” hides that distinction. Let AI summarize an exception after these fields are established; do not ask it to infer which occurrence authorized a send. Keep customer content out of this diagnostic record unless it is genuinely necessary.

Rehearse with harmless data

Use a test environment and harmless records. Cover an ordinary day, both fall-back occurrences, a nonexistent spring time, and a worker failure midway through processing. Add a West Coast location and a non-DST location appropriate to the business. For each case, write expected report count, business date, and delivery count before running it. Use a simulated inbox so the exercise cannot contact customers. Treat a time-zone conversion check as only one component: the scheduler, worker, and delivery path still need their own evidence.

Reconcile before a catch-up run

When a run appears missing, inspect the business record and delivery receipt before choosing catch-up, skip, or manual review. A generated but unsent report differs from one sent with a lost acknowledgment. Preserve the original business identity during recovery and record the owner’s decision. If delivery cannot be established, show that uncertainty instead of automatically sending again. A green scheduler dashboard alone does not establish that the intended recipient received the correct report.

Leave one usable schedule contract

Start this week with one important scheduled workflow. Its one-page contract should name the zone, business-date boundary, repeated-time and missing-time behavior, recovery owner, and evidence of completion. Review the first affected run against that contract after the transition. Keep the test fixtures for the next clock change and rerun them when the scheduling service or configuration changes. The aim is a team that can explain when work was due and whether it finished, without relying on an operator remembering last year’s workaround.