Cron Timezone Converter

Why Convert Cron Schedules Between Timezones?

Cron expressions specify when a job runs, but they don’t specify where. A cron schedule of 0 9 * * * means 9:00 AM in whatever timezone the server or scheduler is configured to use. This becomes a problem when your team spans multiple timezones, or when you need to translate a UTC-based schedule (like AWS CloudWatch, GitHub Actions, or Kubernetes CronJobs) into your local time.

This tool takes a cron expression interpreted in one timezone and shows you the exact execution times in another timezone. It uses your browser’s built-in Intl.DateTimeFormat API, which correctly handles Daylight Saving Time (DST) transitions — so you’ll see the actual clock times even when DST shifts occur.

Common Conversion Scenarios

• GitHub Actions / Kubernetes — Schedules run in UTC. Convert to your local timezone to understand when they actually fire.
• AWS EventBridge — Supports UTC or specific timezones. Convert between them to coordinate cross-region schedules.
• Team coordination — A deploy window at 0 2 * * 0 UTC means different local times for team members in New York, London, and Tokyo.
• DST transitions — A job scheduled at 2:30 AM local time may skip or double-fire during DST changes. Converting to UTC reveals the actual behavior.

How DST Affects Cron Schedules

If your cron daemon runs in a timezone that observes DST (like America/New_York), be aware of edge cases during spring-forward and fall-back transitions. For example, a job scheduled at 30 2 * * * (2:30 AM) in America/New_York will be skipped entirely on the second Sunday of March when clocks jump from 2:00 AM to 3:00 AM. Conversely, during the fall-back in November, a 1:30 AM job may run twice. This tool shows you the real execution times through DST transitions, so you can spot these issues before they cause problems in production.