Cron and time zones: server time, UTC and daylight saving

A cron schedule has no time zone of its own. It borrows one, and the borrowed one is often not yours.

Linux and Mac

Ordinary cron reads the clock of the machine. If a server is set to UTC, 0 9 * * * runs at 09:00 UTC. The manual's example crontab sets a zone for the file with a line CRON_TZ=Japan before the job lines, so the jobs under it follow that zone. Check the cron program on your system before relying on this, because support for the variable depends on the version.

GitHub Actions

GitHub's page says that by default scheduled workflows run in UTC, and that you can optionally set a time zone with an IANA zone name. The example from the page:

on:
  schedule:
    - cron: '30 5 * * 1-5'
      timezone: "America/New_York"

This runs at 5:30 AM New York time every Monday to Friday. IANA names look like Asia/Kolkata or Europe/London, not abbreviations such as IST. The page also says that for a zone with daylight saving time, in the hour that is skipped when the clocks go forward, a scheduled workflow advances to the next valid time: a 2:30 AM schedule runs at 3:00 AM.

Kubernetes

Kubernetes says that a CronJob with no time zone uses the time zone of the kube-controller-manager. Since version 1.27 (stable) you set .spec.timeZone to an IANA name, for example "Etc/UTC". Writing CRON_TZ or TZ inside the schedule text is not supported and gives a validation error.

Converting to and from UTC

India has no daylight saving, so the offset is constant: India time is UTC plus 5 hours 30 minutes. To run at 09:00 India time on a UTC server, subtract: 09:00 minus 5:30 is 03:30, so the hour is 3 and the minute 30: 30 3 * * *. For 00:00 India time the answer is 18:30 UTC of the previous day, so 30 18 * * *. When the conversion crosses midnight, the day field moves too: a job at 03:00 India time on the 1st of the month is 21:30 UTC on the last day of the previous month, which cannot be written as one plain cron line.

Daylight saving time

The cronie manual is blunt about it: non-existent times, such as the missing hour when clocks go forward, will never match, so jobs scheduled in the missing time are not run. Times that occur more than once, when the clocks go back, will cause matching jobs to run twice. Quartz's tutorial gives the same warning for the hour before and after 2:00 AM in US locales.

We checked this with the engine behind the tool, using the Europe/London zone. In 2027 the clocks go forward on Sunday 28 March, so a 30 1 * * * schedule has no run on that day: 01:30 does not exist. In 2026 the clocks go back on Sunday 25 October, and the same schedule runs twice that day, at 01:30 summer time (00:30 UTC) and again at 01:30 winter time (01:30 UTC). To see it yourself, choose that zone and set the number of runs to 20 a few days before the change.

The practical advice is simple. Run important jobs in UTC when you can, or avoid the hours between 1:00 and 3:00 at night in zones that change their clocks. Make jobs safe to run twice.

This is an independent guide and tool. It is not connected with crontab.guru, Quartz, GitHub, Kubernetes, Spring or the Linux projects named here. Product names belong to their owners.