Cron Job Wrong Timezone: Why Your Job Runs at the Wrong Time

Understanding Cron Timezones

Cron uses your system's timezone to interpret schedule times. If your server is set to UTC but you scheduled a job for 9 AM thinking it would run at 9 AM local time, you've got a problem.

This is especially common with:

• Cloud servers (usually default to UTC)
• Docker containers (often UTC)
• Remote VPS providers
• After server migrations

Check Your Current Timezone

First, find out what timezone your server is using:

# Check system timezone
timedatectl

# Or simply
date
# Output: Wed Dec 25 14:30:00 UTC 2025

# See the timezone file
cat /etc/timezone
# Output: Etc/UTC

If it shows UTC and you expected something else, that's your problem.

Solution 1: Change System Timezone

The most straightforward fix is to set the system timezone to match your local time:

# List available timezones
timedatectl list-timezones

# Set timezone (example: US Eastern)
sudo timedatectl set-timezone America/New_York

# Verify the change
date

Important: After changing the system timezone, restart the cron daemon:

sudo systemctl restart cron
# Or on some systems:
sudo systemctl restart crond

Solution 2: Set Timezone in Crontab

Some cron implementations (like Vixie cron on newer systems) support a CRON_TZ variable:

CRON_TZ=America/New_York

# This job runs at 9 AM New York time
0 9 * * * /home/user/scripts/backup.sh

This only affects jobs below the CRON_TZ line in that crontab. You can even have multiple timezones in one crontab:

CRON_TZ=America/New_York
0 9 * * * /scripts/ny-report.sh

CRON_TZ=Europe/London
0 9 * * * /scripts/london-report.sh

Note: Not all cron implementations support CRON_TZ. Test it on your system first.

Solution 3: Convert Times Manually

If you can't change the system timezone and CRON_TZ isn't supported, manually convert your desired time to UTC:

# I want 9 AM EST (UTC-5) → 14:00 UTC
0 14 * * * /home/user/scripts/backup.sh

# I want 9 AM PST (UTC-8) → 17:00 UTC
0 17 * * * /home/user/scripts/backup.sh

Warning: This gets complicated with Daylight Saving Time. EST becomes EDT (UTC-4) in summer, so your 9 AM job would run at 10 AM instead.

Solution 4: Handle Timezone in Script

For complex scenarios, run the job frequently and let the script decide if it should execute:

# Run every hour, script checks if it's the right time
0 * * * * /home/user/scripts/timezone-aware-job.sh

The script:

#!/bin/bash

# Check if it's 9 AM in New York
HOUR=$(TZ=America/New_York date +%H)

if [ "$HOUR" != "09" ]; then
    exit 0  # Not the right hour, skip
fi

# Do the actual work
/home/user/scripts/backup.sh

Daylight Saving Time Gotchas

DST causes two problems:

• Spring forward: 2 AM becomes 3 AM. Jobs scheduled for 2:00-2:59 AM don't run at all.
• Fall back: 2 AM happens twice. Jobs scheduled for 1:00-1:59 AM might run twice.

If your job is time-sensitive, either:

• Use UTC (no DST changes)
• Avoid scheduling during the 1-3 AM window
• Make your script idempotent (safe to run twice)

Docker and Containers

Container images typically use UTC. Set the timezone when starting the container:

# Docker run
docker run -e TZ=America/New_York myimage

# Docker Compose
services:
  myapp:
    environment:
      - TZ=America/New_York

# Kubernetes
env:
  - name: TZ
    value: "America/New_York"

Quick Reference: Common Timezone Offsets

US Eastern (EST/EDT):    UTC-5 / UTC-4
US Central (CST/CDT):    UTC-6 / UTC-5
US Pacific (PST/PDT):    UTC-8 / UTC-7
UK (GMT/BST):            UTC+0 / UTC+1
Central Europe (CET):    UTC+1 / UTC+2
India (IST):             UTC+5:30
Japan (JST):             UTC+9
Australia East (AEST):   UTC+10 / UTC+11

Verify Your Fix

After making changes, test with a job that runs in a minute:

# Edit crontab
crontab -e

# Add a test job (adjust time to 1 minute from now)
42 15 * * * echo "Test: $(date)" >> /tmp/cron-tz-test.log

Check the log file to confirm it ran at the expected time.