Quick answer: Check the current setting with timedatectl, list zones with timedatectl list-timezones, and set one with e.g. sudo timedatectl set-timezone Europe/Kyiv. The timezone affects cron schedules and log timestamps, so set it consciously.
Overview
Fresh servers usually run in UTC. That is a perfectly good choice — many teams keep servers on UTC so logs from different locations line up. Set a local timezone when human-facing schedules (reports, backups at "3 AM local") matter more.
Before you start
- Root/sudo access.
- A decision: UTC for uniformity, or local time for convenience.
Step-by-step guide
- Inspect the current state:
timedatectl - Find your zone:
timedatectl list-timezones | grep -i kyiv - Set it:
sudo timedatectl set-timezone Europe/Kyiv - Keep the clock accurate — enable NTP sync:
sudo timedatectl set-ntp true timedatectl # "System clock synchronized: yes" - Restart cron so it picks up the change:
sudo systemctl restart cron # Debian family (crond on RHEL family)
Common issues
- Cron jobs fire at the "wrong" hour after a change: restart the cron service; schedules are interpreted in the new zone.
- Logs mix timezones: some apps log in UTC regardless — check each app's config before assuming the clock is wrong.
- Clock drift: ensure NTP is on (
set-ntp true); drifting clocks break TLS, tokens and replication.
When to contact support
Timezone and clock settings are OS-level and under your control; if time drifts heavily even with NTP enabled, open a ticket so we can check the platform side.
Frequently asked questions
Should my server use UTC or local time?
UTC is the common choice because logs from every location line up. Use local time when human-facing schedules, such as backups at 3 AM local, matter more to you.
Do cron jobs follow the new timezone immediately?
Restart the cron service after changing the timezone. Cron interprets schedules in the system timezone that was active when the daemon started.
Related articles
Need a hand? Contact Cloud2Y support →
