Context
“Run every day at nine” is incomplete when customers live in different time zones. Nine in Kolkata, London, and New York refers to different moments. Some locations also change their clocks during the year. A scheduler can evaluate an expression correctly while the business report covers the wrong date or runs outside the customer's working day.
Imagine an illustrative SaaS platform sending a daily account summary. It was originally built around a fixed UTC offset for every customer. After a daylight saving transition, customers in one region receive the summary an hour late. The issue is not necessarily delayed infrastructure; the schedule may be expressing the wrong business rule.
Choose calendar time or elapsed time
EventBridge Scheduler supports rate, cron, and one-time schedules, including named time zones. AWS documents that a cron occurrence in a skipped spring-forward time is skipped, and a repeated fall-back time is invoked once. A rate expressed in days represents a 24-hour duration rather than a promise to preserve a local wall-clock hour across daylight saving changes. 1
Ask the product owner which meaning is intended. A maintenance check every 24 hours is different from a customer report at 09:00 local time. Record the selected time zone using its recognised name and retain the original customer preference. A numeric offset alone does not describe future clock changes.
Define the business date separately from dispatch time
The time at which a handler starts should not automatically determine the reporting period. A delayed run just after midnight could otherwise process the wrong date. Carry a stable job identity and the intended business date or period boundary into the execution design. Derive the data window using the customer's calendar rules.
For a daily report, define whether the period is the previous local calendar day, the last 24 hours, or a trading day with a special close. Store the resulting UTC start and end instants for audit. This makes an unusual 23-hour or 25-hour local day explainable without pretending every business day has equal elapsed duration.
Treat dispatch and completion as different events
A scheduler invoking a target does not prove that the business task finished. The target may enqueue work, fail after accepting it, or complete only part of a batch. Maintain a completion record keyed by tenant, job type, and intended period. It should distinguish requested, running, completed, and failed work.
The completion record also supports duplicate handling. If a retry arrives after a report has already been published, the handler should recognise the completed business operation instead of sending another copy. A lock can coordinate active execution, but the durable completion state explains what happened after a process dies and the lock disappears.
Make late work an explicit product decision
Some tasks should run late because a missing report is worse than a delayed one. Others should expire because a notification after the relevant event is confusing. Define a maximum acceptable lateness for each job type. Separate that business deadline from infrastructure retry settings and queue retention.
When a run misses its deadline, choose a visible outcome: backfill, skip with a recorded reason, or request operator review. Do not silently mark it successful because no exception remained. A dashboard should show the last completed business period, not only the timestamp of the most recent handler invocation.
Test the calendar edges before customers encounter them
Build a table of representative dates around clock changes for each supported time zone. Include a skipped local time, a repeated local time, month-end, year-end, and a customer who changes their time zone. Verify the next scheduled occurrences and the reporting windows independently.
Use test targets that record intended and actual execution time without contacting real customers. For a customer time-zone change, decide whether the current period belongs to the old schedule or the new one. Otherwise a well-intended configuration edit can create two reports for one period or none at all.
Keep operator timestamps unambiguous
Store machine timestamps in a consistent format with timezone information. Show the customer's local time and the corresponding UTC instant in operational views where both are useful. Avoid labels such as “yesterday” in incident evidence without a date and time zone. Teams working across countries need to compare the same event reliably.
Allow operations to replay one business period through an authorized workflow. A replay should keep its original period identity and explain whether it will regenerate, replace, or merely re-deliver an existing artifact. Replaying a raw timestamp without that contract can create duplicate downstream actions.
Verify the schedule with a business ledger
Track expected periods against completed periods, with a freshness target appropriate to the product. This catches a disabled schedule, a misconfigured target, or a handler that returns successfully before doing useful work. The ledger also gives support a concrete answer when a customer asks about a missing report.
A focused operator exercise: A customer time-zone change example
Suppose a customer changes their reporting time zone after the day's report has already completed. The product must decide when the new calendar rule becomes effective. Store that effective boundary and keep the completed period identity so the next scheduler invocation does not create a second report for an already satisfied business obligation.
Test the change with an uncompleted period as well. The expected result should identify which local dates are covered, their UTC boundaries, and whether a late report is generated or skipped deliberately. This turns a time-zone setting into a defined business transition instead of an implicit rewrite of every future and pending job.
Quick diagnostic map
| Evidence | Review | Acceptance boundary |
|---|---|---|
| Time-zone rule | Inspect the named zone and local schedule | Model daylight-saving transitions |
| Business identity | Derive the intended business date | Deduplicate by work identity |
| Completion ledger | Reconcile expected periods with outcomes | Make catch-up work explicit |
Frequently asked questions
Should all schedules use UTC? UTC is useful for elapsed-time work and shared operational records. Customer calendar events may need a named local time zone.
Does one invocation mean one completed report? No. Dispatch, processing, publication, and delivery are separate outcomes. Clouvenix can help translate those outcomes into a schedule and runbook that remain understandable across regions and seasonal clock changes.
For a scoped review of this workflow, discuss the relevant Clouvenix engineering service.