> ## Documentation Index
> Fetch the complete documentation index at: https://docs.notifly.tech/llms.txt
> Use this file to discover all available pages before exploring further.

# Manage campaigns across time zones and daylight saving time

> Understand when messages reach overseas customers and adjust existing campaigns to keep your preferred local send time after a daylight saving time change.

## Before you start

Choosing a region such as `America/New_York` under **Set Timezone** sends to everyone **according to that region's clock**. Choosing **Recipient's time zone** sends separately according to the time zone recorded for each device (user). Selecting New York does not make every recipient receive the message at the same time on their own local clock.

**Daylight saving time (DST) is a seasonal change to local clocks.** Whether it applies, and when clocks change, depends on the region. The effect on your campaign depends on the delivery method below.

<Note>
  The difference shown beside a time zone, such as `-04:00`, and **Local Time** reflect the current moment. The
  difference may be different on a future delivery date. Do not manually add or subtract an hour from **Delivery
  Time** to match this display. Enter your intended region and local time.
</Note>

## How do delivery methods differ?

Check the method selected under **Delivery Timing** together with **Set Timezone**. The times below determine when sending starts. Processing and channel conditions may delay when recipients actually receive the message.

| Delivery method | Which time determines sending? | Do I need to adjust for DST? |
| - | - | - |
| **Immediate Delivery** | Sending starts when you create the campaign. | There is no scheduled time to adjust for DST. Run it at your intended local time. |
| **One-Time Scheduled Delivery** + a region | Sends once at the **date and time in the selected region**. | DST on the scheduled date is taken into account. If the region, date, and time are correct, you do not need to save again because of the clock change. |
| **Daily Scheduled Delivery** + a region | Repeats at fixed daily intervals from the first scheduled send time. | The local send time may shift by one hour after a clock change. To keep the same local time, [edit and save the existing campaign](#how-do-i-keep-the-same-local-time-after-a-clock-change). |
| **Scheduled Delivery on Specified Days** + a region | Repeats at the chosen weekly interval from the first scheduled time for each selected weekday. | The local time may shift for both weekly and every-other-week campaigns. Edit and save to restore the intended time, and also check the delivery weeks for intervals of two weeks or more. |
| Scheduled delivery + **Recipient's time zone** | Sends according to each device's (user's) time zone. Uses **Set Default Timezone** when that information is missing. | Each time zone's DST is taken into account, so recurring sends at ordinary local times do not need editing at every clock change. Check that the default time zone is appropriate. |
| **Event-Based Send** | Sends immediately after an event or after the wait set in **Delay After Event Occurrence**. The campaign validity period uses the time zone of the browser where you configure it. | This does not schedule a fixed local time each day. If you want a fixed waiting period, you do not need to change the delay for DST. Check [quiet hours](#how-do-quiet-hours-and-delayed-sending-work) separately. |
| **API-Triggered Send** | Runs when an external system requests delivery. | The external system must make its requests at the intended local time. Confirm the request schedule with your integration team. See the [Campaign Trigger API guide (Korean)](/api-reference/trigger-campaign) for request details. |

<Warning>
  When clocks move forward, some local times do not occur. When clocks move back, some occur twice. Do not assume that
  a send during those hours will run at your intended time or frequency. Avoid those hours on the transition date, or
  contact Notifly. Region-based recurring sends near midnight may also shift to a different local date or weekday
  after a clock change.
</Warning>

## When is the recurring schedule established?

Recurring delivery is based on **the first scheduled send time calculated when you create or edit and save the campaign**. The start of **Delivery Date**, the first scheduled send time, and the date of the first successful send can be different.

For example, suppose you save a campaign in advance with a period starting on Sunday and delivery at 22:00 on Monday, Wednesday, and Friday.

| What it means | In this example |
| - | - |
| Start of **Delivery Date** | The campaign period starts on Sunday. This does not mean it sends on Sunday. |
| First scheduled send time used for recurring delivery | Monday at 22:00. Wednesday and Friday also repeat at the selected weekly interval from their own first scheduled times. |
| Date of the first successful send | If there are no recipients on Monday, or the send fails, and the first successful send is on Wednesday, this date is Wednesday. That outcome does not move the recurring schedule's starting point to Wednesday. |

Whether the first scheduled time falls before or after a clock change affects the local time maintained by later recurring sends. Do not judge this from the start of the campaign period alone.

**If you edit and save while keeping a start date in the past**, the first available future send time is calculated again. Past deliveries are not sent all at once to catch up. If the selected time has already passed that day, the schedule starts on the next eligible date.

<Warning>
  For intervals of **two weeks or more**, the newly calculated first scheduled date can also change which weeks
  receive messages. Read [the delivery-week check](#for-intervals-of-two-weeks-or-more) before editing if you need to
  preserve the existing weeks.
</Warning>

## How do I keep the same local time after a clock change?

### For daily or weekly sends, keep the settings and save the edit

For a recurring campaign with a selected region, complete the steps below **after the clock change, but before the earlier of the existing scheduled time and your intended time**. You do not need to create a new campaign or shift the time by one hour.

For example, a campaign that sent daily at 22:00 New York time immediately before the change may behave as follows.

| Clock change | Without editing | After editing and saving the same settings following the change |
| - | - | - |
| DST starts | May send at 23:00 in New York. | Recurring delivery starts again at 22:00 in New York. |
| DST ends | May send at 21:00 in New York. | Recurring delivery starts again at 22:00 in New York. |

<Warning>
  If the campaign has already sent that day and you save again before 22:00, **another send may be scheduled for the
  same day**. Saving after your intended time has passed may instead leave that day's send out. Check that day's
  delivery results before editing. Pausing or editing does not guarantee cancellation of messages already being
  processed for delivery.
</Warning>

1. In the **Campaign** list, open the campaign's actions menu. If it is active, choose **Pause Campaign**, then **Edit Campaign**. If it is already inactive, go straight to editing.

   <Warning>
     Pausing and resuming are only available until five minutes before execution. Allow enough time to edit and
     resume before the scheduled time passes. Missed scheduled sends during a pause are not automatically caught up.
   </Warning>

2. Under **Delivery Timing** → **Scheduled Send**, check the following. If the values are correct, **you do not need to change any of them**.

   * **Delivery Frequency**: Keep **Daily Scheduled Delivery** or **Scheduled Delivery on Specified Days**. For weekly delivery, keep **Set Frequency** at 1 and retain the existing **Delivery Days**.
   * **Delivery Time**: Keep the intended local time, **22:00**. If it is wrong, change it to 22:00.
   * **Set Timezone**: Keep **America/New\_York**. If another region is selected, change it to your intended region.
   * **Delivery Date**: Keep the existing start and end dates, or **Send Indefinitely**. A start date in the past does not have to be changed. Keep the audience and message unchanged as well.

3. Select **Final Confirmation**, review the time, time zone, period, and weekdays, then select **Edit Campaign**. Do not finish with **Save as Draft**. After saving an inactive campaign, choose **Resume Campaign** in the prompt to activate it again. If you need to check more details first, choose **Keep Inactive**, then use **Resume Campaign** from the list when ready.

4. After saving, check that the status is **Active** and that the settings in **Campaign Details**, available from the actions menu, are still correct. After the first send, check the results in **Campaign Delivery Status**. The current difference shown beside the time zone does not establish when the next send will occur.

This requires **saving through the edit screen**. **Pausing and choosing Resume Campaign alone does not realign the send time.** To keep the same local time through the next DST change, check and adjust the campaign again.

### For intervals of two weeks or more

Saving an edit may change the delivery weeks, so check the next intended week as well as **Delivery Time** and **Delivery Days**. For example, an every-other-week Monday campaign that was due two Mondays from now may start on the coming Monday if saved this week.

If only one weekday is selected and you need to keep the existing delivery weeks, set the start of **Delivery Date** to **a time before the send time on your next intended delivery date, after the DST change**. Keep **Set Frequency**, **Delivery Days**, **Delivery Time**, **Set Timezone**, and the end date, then save and resume using the steps above. With multiple weekdays, their next intended dates may fall in different weeks. Do not assume that changing one start date can preserve every weekday's existing schedule; contact Notifly before editing.

<Warning>
  **Moving the start date later excludes remaining sends before that new start.** For example, moving it to tomorrow
  excludes today's remaining 22:00 send. Do not move the start date if you need to keep a send before it. Contact
  Notifly before editing if you are unsure how the delivery weeks line up.
</Warning>

### What can I do with an existing campaign?

| Method | Does it realign the local send time? |
| - | - |
| Pause, then choose **Resume Campaign** without saving settings | No. It keeps the existing recurring schedule. |
| Keep the reservation settings in **Edit Campaign**, then select **Final Confirmation** → **Edit Campaign** | Yes. Saving after the clock change recalculates the first future scheduled time. This is the recommended option for daily and weekly sends. |
| Keep the start date, change **Delivery Time** or another delivery setting, and save | Yes. The final values must be the intended local time and region. Do not manually compensate by adding or subtracting an hour. |
| Move the start date to a date after the clock change and save | Yes, but remaining sends before the new start are excluded. This is unnecessary when you only need to realign a daily or weekly send time. |

## How do quiet hours and delayed sending work?

### Can a message be sent now? The quiet-hours region determines this

If **Use Quiet Hours** is set to New York and **21:00–08:00**, messages are blocked during those hours on New York's local clock. The **check on whether sending is allowed** continues to use New York local time after DST changes. Keep the region and start/end times if you want the same quiet-hours window.

For an event-based campaign, configure the region and hours under **Delivery Timing** → **Event-Based Send** → **Frequency Capping and Quiet Hours** → **Use Quiet Hours**. This uses the region selected here, separately from the scheduled-delivery option **Recipient's time zone**.

<Note>
  The restriction starts **three minutes before** the configured start to help prevent processing from crossing into
  quiet hours. A 21:00 start can therefore block sending from 20:57. Avoid planning a send immediately before that
  boundary.
</Note>

### When is a blocked message sent? Check whether delayed sending is allowed

In an event-based campaign, selecting **Allow delayed sending** schedules a message blocked by quiet hours for later delivery after quiet hours end. A message blocked at 22:00 New York time normally becomes eligible after 08:00 the following day. Without this option, that message is skipped.

To keep this behavior, retain the region and hours in **Use Quiet Hours** and your **Allow delayed sending** selection. If the message must arrive at a particular time, account for the exception below and plan it outside the overnight quiet-hours window on transition dates.

<Warning>
  **If quiet hours continue into the next day and DST changes overnight**, the delayed send time may differ from the
  end of quiet hours by one hour. With New York quiet hours of 21:00–08:00, a message blocked the night before DST
  starts may be delayed until 09:00 the next day. The night before DST ends, it may be scheduled for 07:00; sending is
  checked again at that time, and a message still within quiet hours is deferred again. Do not promise an exact 08:00
  send on a transition date; check the results.
</Warning>

### Project-wide and channel restrictions also apply

If **Settings** → **Project Info** → **Global Quiet Hours** applies to the channel, it can block sending even outside the campaign's own quiet hours. Check the time zone of each setting separately. Enabling only Global Quiet Hours does not automatically allow delayed sending. See the [project settings guide (Korean)](/ko/user-guide/console/setting#3-3-전역-야간-발송-제한) for details.

Kakao Friend Talk and Brand Message also have separate quiet-hours restrictions based on Korean time. **Ignore Global Quiet Hours** does not override a channel's own restrictions. See the [KakaoTalk guide (Korean)](/ko/user-guide/channel/kakaotalk/setup) for channel-specific guidance.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="Will turning a campaign off and on realign its send time?">
    Pausing and resuming alone will not realign it. Follow the [edit-and-save
    steps](#how-do-i-keep-the-same-local-time-after-a-clock-change).
  </Accordion>

  <Accordion title="Do I have to change the start date?">
    No. Daily and weekly sends can keep a start date in the past. If you change it to preserve [delivery weeks for
    longer intervals](#for-intervals-of-two-weeks-or-more), check whether remaining sends before the new start will
    be excluded.
  </Accordion>

  <Accordion title="Does a failed send change the recurring schedule's starting point?">
    No. The schedule stays in place even if there are no recipients or a send fails. See [the difference between the
    first scheduled time and the first successful send](#when-is-the-recurring-schedule-established).
  </Accordion>

  <Accordion title="Is it OK if the displayed time difference differs from the scheduled date's?">
    Yes. The current display and a future scheduled date can have different time differences. [Set your intended
    region and local time](#before-you-start).
  </Accordion>

  <Accordion title="Will I need to adjust again at the next DST change?">
    For region-based recurring delivery, check and adjust again. With **Recipient's time zone**, ordinary local send
    times do not need editing at every change. See [the delivery-method
    comparison](#how-do-delivery-methods-differ).
  </Accordion>
</AccordionGroup>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.