Timezones and daylight saving

Every CronJobPro job carries its own timezone, and your schedule is evaluated in that timezone rather than on the server clock. This page explains how that behaves across daylight saving transitions and how to schedule without surprises.

How the per-job timezone works

When you create or edit a job you pick a timezone alongside the schedule. CronJobPro reads your cron expression or interval in that timezone, then converts each upcoming run to an absolute moment and fires the HTTP request from its servers. Two jobs with the same 09:00 daily schedule but different timezones will run at different absolute times, exactly as you would expect.

Local clock time stays stable across DST

CronJobPro keeps your local clock time fixed through daylight saving transitions. A job set to 09:00 daily in a timezone that observes DST keeps running at 09:00 local time both in winter and in summer, even though its absolute UTC time shifts by an hour when the clocks change. You do not need to edit anything around the changeover dates.

The spring-forward gap gotcha

Twice a year the local clock is not continuous, and that can affect scheduled times that fall inside the discontinuity:

• Spring forward: the clock jumps ahead, so a window of local times never occurs that day. A run scheduled inside that gap may be skipped or shifted, because the wall-clock time it targets does not exist.
• Fall back: the clock repeats an hour, so a local time occurs twice. A run scheduled inside the repeated hour can be ambiguous about which occurrence applies.

Use UTC for ambiguity-free scheduling

UTC never observes daylight saving, so it has no skipped or repeated hours. Choosing UTC as the job timezone makes every run time unambiguous and keeps the absolute interval between runs constant year-round. This is the safest choice for back-end jobs, sync tasks, and anything where the exact local hour does not matter. Note that your plan's daily-run quota is always counted in UTC regardless of the timezone you pick for the job.

1. 1

   Open the job

   Go to your job in the dashboard and edit its schedule settings.

2. 2

   Set the timezone

   Choose UTC for ambiguity-free scheduling, or a local timezone if the run must happen at a specific wall-clock hour.

3. 3

   Check the transition window

   If you keep a local timezone, confirm your run time does not fall in the early-morning DST changeover window.

4. 4

   Confirm the next run

   Save and verify the next scheduled run time shown for the job matches what you expect.

To translate a local time into UTC, or to see how a schedule lands across different zones, use the Timezone Converter tool.

Open the Timezone Converter →