# Timezones and daylight saving time

Every job has an IANA timezone (`Europe/London`, `America/New_York`, `Asia/Kolkata`). Wall-clock schedules like `every day at 9am` fire at 09:00 local time all year, even as the UTC offset changes. When daylight saving time creates a missing hour, cronpad fires at the first valid moment after it; when it creates a repeated hour, cronpad fires once.

## Choosing a timezone

- The dashboard defaults to your browser's timezone. The API defaults to `UTC`.
- Use IANA names, not abbreviations: `America/Los_Angeles`, not `PST`.
- Times in API responses are always UTC (RFC 3339 with `Z`). The dashboard shows both the job's timezone and yours.

## Daylight saving rules

### Clocks go forward (a time doesn't exist)

In `America/New_York` on 8 March 2026, clocks jump from 02:00 to 03:00. A job at `every day at 2:30am` would fire at a time that doesn't exist that night.

**cronpad fires at 03:00**, the first valid instant after the gap. It never silently skips a day.

### Clocks go back (a time happens twice)

On 1 November 2026, 01:00–02:00 happens twice in `America/New_York`. A job at `every day at 1:30am` fires **once**, at the first 01:30 (EDT).

### Fixed intervals ignore DST

Interval schedules measure real elapsed time: `every 1 hour`, `every 15 minutes`, `@every 90m`. They fire exactly every hour across a DST change, so the local clock time of each run shifts by an hour.

| Schedule | Across a DST change |
|---|---|
| `every day at 9am`, `0 9 * * *` | Stays at 09:00 local time |
| `@hourly`, `0 * * * *` | On the hour, local time. The missing hour has no run; the repeated hour runs once. |
| `every 1 hour`, `@every 1h` | Exactly every 60 minutes of real time |
| `every 24 hours` | Exactly every 24 h of real time, so it drifts from 09:00 to 10:00 (or 08:00) local |

Tip: use `every day at …` rather than `every 24 hours` when you mean a time of day.

## Timezones without DST

Zones like `Asia/Kolkata` or `UTC` have no transitions; none of the above applies.

## Timezone database

cronpad embeds the IANA timezone database in its binary, so results don't depend on the host system. Upgrading cronpad picks up timezone rule changes.