Daylight Saving Report Schedules: Avoid Missed and Doubled Reports

Twice a year, a report schedule that has run flawlessly for months can arrive an hour late, an hour early, twice, or not at all. The cause is rarely the BI tool itself. It is how the schedule was defined: against a fixed offset or the server's clock, with an interval or a wall-clock time, with or without a time zone. This guide explains what actually happens at each clock change, how to set schedules so reports land at the intended local time, and how to check afterward that every delivery went out once.

ChristianSteven Software

Keep Report Delivery on Schedule

ChristianSteven automates report generation and delivery across Power BI, SSRS, Tableau, and Crystal Reports for more reliable reporting workflows.

Discuss your reporting needs

TL;DR

Schedules defined by wall-clock time plus an explicit time zone (such as America/Chicago) hold their local time across a change. Schedules with no time zone, or simple intervals, drift by an hour.
The spring hour that does not exist and the fall hour that happens twice are the two danger zones. Avoid placing important jobs between 1:00 and 3:00 a.m. local time on change nights.
Different schedulers resolve the ambiguity differently: some run the job once in the first pass, some run it in the repeated hour, and some may run it twice. Read your tool's rule before the change, not after.
Test with a dry run of the transition, and monitor generation and delivery as separate steps.

Why daylight saving time breaks report schedules
How time zones should work in a schedule
What happens in the skipped hour and the repeated hour
What this means in Power BI, SSRS, Tableau and Crystal Reports
Recipients in different time zones
How to configure schedules before the change
How to test a transition
Monitoring and audit records across a change
When a report arrives at the wrong time or does not run
Our perspective: take the clock out of the critical path
Automating this with ChristianSteven
FAQ
Sources

Why daylight saving time breaks report schedules

A scheduler has to answer one question: when is the next run? That sounds simple until local time stops being continuous. In the United States, clocks spring forward at 2 a.m. local time in March, so the clock jumps from 1:59 to 3:00. In the fall, the clocks move back one hour on the first Sunday in November, so every time between 1:00 and 2:00 a.m. occurs twice.

That creates three failure patterns:

Drift. The job keeps running at the same moment in absolute time, so the local arrival time moves by an hour. Your 7:00 a.m. executive summary becomes 8:00 a.m., or 6:00 a.m.
Skipped runs. A job set for 2:30 a.m. on the spring change night is scheduled for a time that never appears on the wall clock.
Duplicate runs. A job set for 1:30 a.m. on the fall change night matches two moments, and some schedulers fire for both.

For reports, the impact goes beyond annoyance. A finance team that expects a morning cash position before the market opens, or an operations lead who reads a shift report at handover, notices an hour of drift immediately. A duplicate send to external recipients is harder to explain.

How time zones should work in a schedule

The core rule: a schedule needs a named time zone, not just a clock time. A named zone such as America/New_York carries the daylight saving rules with it. A fixed offset such as UTC-5 does not, and it will be wrong for half the year.

Documentation from workflow tools shows the effect plainly. In Catalytic's scheduled trigger, selecting a time zone sets the zone used for DST adjustments and does not change when the trigger itself runs. The same page explains that with no time zone set, DST transitions do not occur, so a daily 2:00 PM trigger may appear at 3:00 PM after a DST adjustment, while a trigger set to America/Chicago stays at 2:00 PM.

The lesson applies to any reporting tool, whatever it is called:

Always set the zone explicitly. Do not rely on the server's default, which may be UTC, the data center's region, or whatever the last administrator chose.
Use region names over offsets. Name the zone by region so the rules update with it.
Keep the intent in mind. Decide whether the business intent is "7:00 a.m. wherever the recipient sits" or "one fixed moment for everyone." Those are different schedules.

Two valid models

Model	How it works	Best for	Watch out for
Local wall-clock time	Schedule stores a time of day plus a named zone, and recalculates after each change	Reports people read at a set hour: morning briefings, daily KPI emails	Skipped and repeated hours on change nights
Fixed absolute time (UTC)	Schedule runs at a constant UTC moment	Machine-to-machine feeds, data loads, SFTP drops	Local arrival time shifts by an hour twice a year

Both are correct. Problems come from using one when the audience expects the other. Docebo's help center documents the second model's side effect in a reporting context: a report scheduled for 11:00 AM (GMT+1:00) in DST may go out at 10:00 when clocks switch back, because the timing depends on whether the start date fell in DST or Standard Time.

What happens in the skipped hour and the repeated hour

There is no universal behavior. Each scheduler picks a policy, and you should know which one yours uses. The documented examples show the range.

Spring: the hour that does not exist

In Broadcom's Applications Manager, daily-or-greater jobs scheduled during the spring lost hour become eligible at the top of the hour, so the job still runs rather than vanishing. The go-cron library's maintainers take a similar position: they advocate for behavior in which jobs in skipped hours run immediately, reasoning that this is more predictable than a silent failure.

Not every tool does this. A scheduler that simply never matches the nonexistent time will skip the report without an error, which is the worst outcome because nobody is alerted.

Fall: the hour that happens twice

The same Applications Manager documentation says that in fall, transition-time jobs do not run twice. Jobs without a time zone run in the first hour, while jobs with a time zone run in the repeated hour. Elastic's Watcher executes at the first occurrence of a time during the overlap and skips the second. The go-cron documentation warns that during fall-back transitions, some schedulers may trigger a job twice unless configured to avoid duplicate execution.

So the same job on the same night can run once in the first pass, once in the second pass, or twice, depending on the product and whether a zone is set.

Intervals versus calendar schedules

Interval schedules ("every 2 hours") behave differently from calendar schedules ("daily at 6:00"). The Applications Manager documentation notes that some interval-based schedulers ignore clock changes and continue on elapsed time, while others shift with the wall clock. Broadcom's knowledge base adds that jobs using simple recurrence may be delayed by an hour when DST ends or run an hour earlier when it begins, and that calendar-based recurrence is often more reliable for respecting DST adjustments.

For reports, that points to a practical default: use specific days and times for anything a person expects at a certain hour, and keep intervals for work where elapsed time is the point, such as a refresh every four hours.

What this means in Power BI, SSRS, Tableau and Crystal Reports

Each platform has its own scheduler, and each ties a schedule to a time zone in its own way: through the service, the report server's host, or a repository server. Settings and defaults differ by product, edition and version, so confirm them in your vendor's current documentation instead of assuming. The questions to ask are the same everywhere:

Which time zone does the scheduler use for this schedule: the user's, the server's, or UTC?
Is the schedule stored as a wall-clock time or an interval?
What does it do with a time that is skipped or repeated?
Is the time zone shown anywhere an administrator can see it, or is it implied?

Native subscriptions are generally designed around one server and one clock. That is fine for a single-region team. It gets harder when the same report goes to recipients in New York, Phoenix (which does not observe DST) and London (which changes on different dates than the US). For deeper background on how schedulers are built, see our report scheduling architecture overview for developers. If you run Power BI Report Server, the scheduling and delivery guide covers how its subscriptions work, and Tableau teams can read how to schedule Tableau report delivery.

Recipients in different time zones

The hardest case is one report, many locations. Three approaches work, and the right one depends on what the recipient needs.

One moment for everyone. Run the report at a single time, say 13:00 UTC, and tell recipients when it arrives. This suits data feeds. Local arrival shifts with DST for any region that observes it, so state the zone in the subject line or file name.

One local hour per region. Create a schedule per region, each with its own named zone, each filtered to that region's data. Each group gets its report at 7:00 a.m. their time regardless of the date. This is more schedules to manage, but it matches how people actually work.

Per-recipient local time. A data-driven schedule reads the recipient list from a table or query, including a time zone column, and sends each person's report at their preferred local hour. This is the most flexible and the most dependent on clean data. Store region identifiers like America/New_York in that column, not offsets, so the rules follow the calendar. Practitioners writing about per-user timezone dispatch describe the same pattern: one UTC tick drives the system, and local-time logic decides who is due.

Three approaches to timezone-aware report delivery

Whichever you pick, remember that countries change on different dates. A global team may spend a few weeks each spring and fall with different offsets between offices, even though every individual schedule is correct. Mention this in your runbook so a recipient's "the report is an hour early" ticket is answered in a minute.

How to configure schedules before the change

A short preparation routine, run a week or two before each change, prevents most incidents.

Inventory the schedules. List every recurring report with its time, zone, recurrence type and recipients. Sort by time of day.
Flag the danger window. Mark anything scheduled between 1:00 and 3:00 a.m. local time. Move those jobs outside the window if the business allows. A report no one reads until 7:00 a.m. does not need to run at 2:30 a.m.
Set explicit zones. Replace blank or server-default zones with a named zone on every schedule that has a local-time expectation.
Prefer calendar recurrence. Convert simple interval jobs to specific day-and-time schedules where the audience expects a fixed hour.
Check dependencies. A report that runs after a data refresh inherits the refresh's timing. If the refresh runs on a different clock, the report may generate against stale data after the change. Use an event trigger on refresh completion instead of two clock times when you can.
Decide your overlap policy. For the fall repeat, decide in writing whether the first or second occurrence counts, and that duplicates must be suppressed. Robust scheduling usually means defining a policy for ambiguous or invalid times so behavior is consistent.

Event-driven and data-driven schedules help here because they remove clock arithmetic: "send when the load finishes" has no ambiguous hour. Our guide to automating and scheduling report generation with BI tools explains when to use each type.

How to test a transition

Do not wait for the real change to find out.

Use a test environment with a movable clock. Set the host or scheduler test clock to a few minutes before the change and watch the next runs. Check what happens at 1:59, 2:00 and 3:00 in spring, and at both 1:30s in fall.
Create sentinel schedules. Add low-stakes reports at 1:30, 2:00, 2:30 and 3:00 a.m. to a test recipient list. After the real change, the results show your scheduler's policy without risking a production report.
Compare run times to intent. Examine run logs for the previous change. Did the 7:00 a.m. report go out at 7:00 local time? Did anything run twice?
Test with and without a zone. Run the same schedule with a zone and without, as the Catalytic example suggests, to see if it drifts.

Monitoring and audit records across a change

A report has two steps: generation and delivery. Cron Crew's guidance on monitoring scheduled reports recommends tracking generation and delivery separately, because a report may be generated successfully and still fail to send. Around a time change, that distinction tells you whether to look at the scheduler or at the mail or file destination.

At a minimum, keep for each scheduled run:

scheduled time and zone, and actual start time
generation status and duration
delivery status per destination and per recipient
retry count and final outcome
a unique run identifier, so duplicates are visible

On change nights, add a morning check: count the expected runs against the runs recorded. In spring you expect no missing runs; in fall you expect no extra ones. Retry logic matters too, since a transient failure during the busy hours after a change should not become a missed report. Our article on protocol-aware report delivery retries describes how retries work for IT teams, and for file destinations see our guides to SFTP report delivery and FTP report delivery.

Communication is part of reliability. The same Cron Crew guidance suggests notifying recipients proactively about delays rather than waiting for them to ask, and sending technical alerts to the data team instead of stakeholders. A one-line "today's report will arrive at 8:00 a.m." message costs less than a morning of tickets.

When a report arrives at the wrong time or does not run

Start with the schedule, then work outward. Cron Crew's checklist for scheduled reports covers the usual suspects: scheduler configuration including crontab syntax and time-zone settings, query timeouts, resource availability such as disk and memory, and application logs. Apply it in this order after a change:

Time zone and recurrence type. Is a zone set? Is it an interval or a calendar schedule? This explains most one-hour shifts.
Run history. Did the job start at all? A missing start points to the skipped-hour policy; two starts point to the repeated-hour policy.
Query duration. Reports that aggregate large amounts of data can hit database query timeouts as data grows, and a run pushed an hour later may collide with a heavier workload.
Credentials. Expired or changed service credentials stop schedules without any link to the clock. One university help article describes a Cognos scheduled job failing because the scheduler had to renew its credentials after a password change, and the renewal was manual.
Delivery layer. If generation succeeded, check mail relay, folder permissions and destination availability. For Power BI Report Server, see our troubleshooting page on email subscriptions that stop working.

Do not assume the change is the cause just because it is the most recent event. Rule out credentials and timeouts, which look similar from the recipient's inbox.

Our perspective: take the clock out of the critical path

We have spent more than two decades building report automation for Power BI, SSRS, Tableau and Crystal Reports, and the pattern we see most often is not a bug in a tool. It is a schedule that was set up for one office, one server and one season, then asked to serve an entire organization.

Our view is that clock-based scheduling should be the exception for anything with a dependency. If a report is supposed to go out when a data load finishes, schedule it on that event, not on a guess about how long the load takes. If a report is supposed to reach each manager at the start of their day, drive it from data that names each recipient's location. Those two choices remove most of the exposure to the skipped and repeated hours, because neither relies on a single wall-clock moment.

The second part is visibility. A scheduler that fails quietly is more dangerous than one that fails loudly. Error handling, retries and a delivery record per recipient are what let an IT team say with confidence, on the Monday after a change, that every report went out once. That is what we designed PBRS, ATRS and CRD to support, and it is the standard we would hold any reporting automation to.

— Christian Ofori-Boateng

Automating this with ChristianSteven

If your native subscriptions cannot express "this recipient, this local time, this filter," or you need delivery logs and retries you can trust, our report automation software is built for that gap. PBRS covers Power BI and SSRS, ATRS covers Tableau, and CRD covers Crystal Reports, with flexible schedules, data-driven bursting, event triggers, multiple formats and destinations, and automated error handling. Both subscription and perpetual licenses are available; pricing is not published, so request a trial or demo to see it against your own schedules. For more on what to look for in a scheduler, read our paginated report scheduler feature guide.

FAQ

Does a daily report run twice when clocks fall back?

It depends on the scheduler. Some tools run a job once during the repeated hour and suppress the second pass, while others may fire twice unless configured to avoid it. Check your tool's documented behavior, and add a unique run identifier so a duplicate is easy to spot.

Why did my report arrive an hour late after the clocks changed?

The most common cause is a schedule with no time zone or a simple interval recurrence. These keep running on absolute or elapsed time, so the local arrival time shifts by an hour. Setting a named time zone and using a specific day-and-time schedule usually fixes it.

Should I schedule reports in UTC or local time?

Use UTC for system-to-system feeds where consistency matters more than local hour. Use local time with a named zone for reports people read at a particular hour. Mixed audiences are better served by one schedule per region or a data-driven schedule that reads each recipient's zone.

What should I do about jobs scheduled between 1:00 and 3:00 a.m.?

Move them if the business allows. If they must stay, find out whether your scheduler runs a skipped job at the next valid time in spring and whether it suppresses the repeat in fall, then test that behavior ahead of the change.

How do I confirm every report went out after a change?

Compare expected runs with recorded runs, and check generation and delivery status separately. Look for missing entries in spring and duplicates in fall, and keep the run log as your audit record.

Sources