Cron Timezone Converter
Use this cron timezone converter to turn a schedule in your local time into the UTC expression that GitHub Actions, Vercel and EventBridge rules need, or to see what a UTC cron means for you.
The short answer
Most hosted schedulers read cron in UTC. To schedule in your own time zone, convert the hour to UTC and write that. 9:00 AM in New York is 0 13 * * * in summer time and 0 14 * * * in winter, because New York is UTC-4 or UTC-5 depending on daylight saving time.
0 13 * * *If the platform supports a time zone setting, use that instead and keep the expression in local time.
Convert a cron schedule
Enter a five-field expression and your time zone. The converter shows the UTC version, the next runs in both zones, and warns about daylight saving time.
Cron UTC: what each platform does with time zones
A cron expression has no time zone of its own. The scheduler that reads it applies one, and the defaults differ.
| Platform | Time zone behavior | What to do |
|---|---|---|
| Linux and Unix cron | The system time zone. cronie also reads a CRON_TZ variable in the crontab. | Set the server zone, or add CRON_TZ if your cron supports it. |
| Kubernetes CronJob | The kube-controller-manager's local zone by default; set .spec.timeZone for a named zone (stable since v1.27). | Set spec.timeZone. Do not put TZ= or CRON_TZ= in the schedule: Kubernetes rejects it. |
| GitHub Actions | UTC by default. GitHub's documentation describes an optional timezone key with an IANA name. | Use the key, or convert to UTC. |
| Vercel | Always UTC. | Convert to UTC by hand or with the converter above. |
| AWS EventBridge rules | UTC. | Convert, or use EventBridge Scheduler. |
| AWS EventBridge Scheduler | UTC, or a time zone you specify when you create the schedule. | Set the schedule's time zone. |
| Quartz | The JVM default unless the trigger sets a time zone. | Set the time zone on the trigger. |
Convert 9:00 AM local time to a UTC cron expression
The rule is: take the local time, subtract the UTC offset, and use the result as the hour. Zones with daylight saving time have two offsets, so the answer changes twice a year. The table uses 15 January and 15 July 2027 as the two examples. Sydney is on summer time in January, so its offsets run the other way round, and its 9:00 AM falls on the previous UTC day. For a weekly schedule that also moves the weekday.
| City | UTC offset (15 Jan / 15 Jul) | 9:00 AM local on 15 January, as UTC cron | 9:00 AM local on 15 July, as UTC cron |
|---|---|---|---|
| New York | UTC-5 / UTC-4 | 0 14 * * * | 0 13 * * * |
| Los Angeles | UTC-8 / UTC-7 | 0 17 * * * | 0 16 * * * |
| London | UTC+0 / UTC+1 | 0 9 * * * | 0 8 * * * |
| Berlin | UTC+1 / UTC+2 | 0 8 * * * | 0 7 * * * |
| Karachi | UTC+5 | 0 4 * * * | same all year |
| Kolkata | UTC+5:30 | 30 3 * * * | same all year |
| Tokyo | UTC+9 | 0 0 * * * | same all year |
| Sydney | UTC+11 / UTC+10 | 0 22 * * * | 0 23 * * * |
Zones with a half-hour offset change the minute field as well: 9:00 AM in Kolkata is 03:30 UTC. The converter above handles all of this, including zones not listed here.
Daylight saving time and cron
A UTC expression never moves, so when your local clock changes, the local run time changes with it. A job set to 0 13 * * * runs at 9:00 AM New York time in summer and at 8:00 AM in winter. That is correct behavior, but it surprises people who think in local time.
Schedulers that apply a real time zone have the opposite problem: the local time can be skipped or repeated. EventBridge Scheduler documents that in a spring-forward change the skipped day's invocation is skipped and in a fall-back change a job at a repeated time runs once. GitHub documents that a schedule in a skipped hour advances to the next valid time. For anything important, avoid the 1 AM to 3 AM window in zones that change clocks overnight.
Crossing midnight changes the day of week
Converting to UTC can move the run to the previous or next day, and then the day-of-week field must change too. Every Monday at 9:00 PM in Los Angeles during summer time (UTC-7) is 0 4 * * 2 in UTC, because it is already Tuesday 04:00 there. In winter (UTC-8) it is Tuesday 05:00 UTC. The converter shifts the day for you; by hand, it is easy to forget.
Better than converting by hand
If your platform can hold a time zone, let it. Set timeZone on a Kubernetes CronJob, the timezone key on a GitHub Actions schedule, the time zone of an EventBridge Scheduler schedule, or the time zone of a Quartz trigger. Then the expression stays in local time and daylight saving is handled by the scheduler. Vercel and EventBridge rules offer no such setting, so conversion is the only option there.
Common cron timezone mistakes
- Assuming the server is in your zone. Cloud servers and containers are usually UTC.
- Converting once and forgetting daylight saving time. Decide whether the job should follow the clock or follow UTC.
- Forgetting the weekday shift when the converted hour falls on the next or previous day.
- Putting
TZ=inside a Kubernetes schedule. Usespec.timeZone.
Sources and further reading
Use a tool
Try the schedule from this page in a tool.
