Linux timedatectl: Check Time and Time Zones

The Linux timedatectl command shows the system clock, time zone, hardware-clock setting, and network time synchronization status in one place.

Start with:

timedatectl

Use it when logs appear out of order, a scheduled job runs at the wrong hour, certificate checks fail, or a server disagrees with everyone else about what time it is. Those problems can look unrelated until you notice the clock is seven minutes—or one time zone—off.

Quick timedatectl command reference

Goal	Command
Show time and sync status	`timedatectl`
Show detailed properties	`timedatectl show`
Show available time zones	`timedatectl list-timezones`
Search time zones	`timedatectl list-timezones \| grep -i chicago`
Set the time zone	`sudo timedatectl set-timezone America/New_York`
Enable network time sync	`sudo timedatectl set-ntp true`
Disable network time sync	`sudo timedatectl set-ntp false`
Set time manually	`sudo timedatectl set-time '2026-07-19 13:30:00'`
Show current date separately	`date`
Show UTC time	`date -u`

Checking status is read-only. Changing the time, time zone, or NTP setting needs administrative permission and can affect logs, jobs, authentication, databases, and running applications. Inspect first; change only with approval.

Read timedatectl output

Run:

timedatectl

Typical output looks like this:

               Local time: Sun 2026-07-19 09:14:22 EDT
           Universal time: Sun 2026-07-19 13:14:22 UTC
                 RTC time: Sun 2026-07-19 13:14:21
                Time zone: America/New_York (EDT, -0400)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

The important fields are:

Local time: The time applications normally display on this host.
Universal time: The same moment in UTC.
RTC time: Time reported by the hardware real-time clock, when available.
Time zone: The configured zone plus current abbreviation and UTC offset.
System clock synchronized: Whether the system believes its clock is synchronized.
NTP service: Whether supported network-time synchronization is enabled or active.
RTC in local TZ: Whether the hardware clock is stored as local time. Linux normally expects it in UTC.

Do not focus only on the clock digits. A host can show a plausible local time while using the wrong zone, or have NTP enabled without having completed synchronization.

Check the current time zone

Print only the configured time zone:

timedatectl show -p Timezone --value

Example:

America/New_York

This is useful in scripts and ticket notes because it avoids the rest of the formatted status output.

Also compare local and UTC time:

date
date -u

A common beginner mistake is treating EDT, EST, or another abbreviation as the complete configuration. Named zones such as America/New_York include daylight-saving rules. A fixed offset such as UTC-5 does not automatically change when daylight-saving time begins or ends.

List and set Linux time zones

List valid time-zone names:

timedatectl list-timezones

The list is long, so search it:

timedatectl list-timezones | grep -i new_york

Set the zone with an exact name:

sudo timedatectl set-timezone America/New_York

Then verify:

timedatectl

Changing the time zone normally changes how the same system time is displayed; it does not mean the machine traveled through time. Services may immediately begin formatting new log entries with a different local offset, though, so record the change in the ticket.

For servers, UTC is often easier to operate across regions:

sudo timedatectl set-timezone UTC

Do not switch a production server to UTC just because it sounds tidy. First check application requirements, job schedules, monitoring, and the team’s standard.

Check network time synchronization

Start with the human-readable status:

timedatectl

For script-friendly values:

timedatectl show -p NTPSynchronized --value
timedatectl show -p NTP --value

On a synchronized system, the first command should return:

yes

Enable the system’s supported network-time service with:

sudo timedatectl set-ntp true

Then check again:

timedatectl

set-ntp true does not mean every Linux distribution uses the same daemon. A machine may use systemd-timesyncd, Chrony, another NTP client, or infrastructure supplied by the cloud platform. timedatectl reports systemd’s view, but the service-specific tool may provide the useful server, offset, and reachability details.

Find which time-sync service is running

Check common services without changing them:

systemctl status systemd-timesyncd --no-pager
systemctl status chronyd --no-pager
systemctl status chrony --no-pager
systemctl status ntp --no-pager

Not every command will find a unit. That is normal; distributions package and name time services differently.

For systemd-timesyncd, inspect:

timedatectl timesync-status

If supported, it can show the selected server, poll interval, delay, jitter, and clock offset.

For Chrony, use:

chronyc tracking
chronyc sources -v

These commands help answer whether the service is merely running or actually reaching a time source. A green service status is not proof that firewall rules, DNS, or upstream NTP servers are working.

If service management is unfamiliar, the systemctl beginner guide explains status, start, restart, and enable operations without treating every warning as a reason to restart something.

Why wrong Linux time causes strange tickets

Clock errors spread into systems that depend on timestamps.

TLS and certificate failures

Certificates have “not before” and “not after” times. A clock that is far behind can make a valid certificate look not yet valid. A clock that is ahead can make it look expired.

Check the host time before replacing certificates:

timedatectl
date -u

Authentication failures

Kerberos and some token-based authentication systems reject requests when client and server clocks differ beyond an allowed window. The password may be correct while the clock is not.

Logs that appear out of order

If two servers use different zones or one clock is drifting, events can look reversed. Capture UTC alongside local time and check both hosts before building an incident timeline.

The Linux log-reading guide covers journalctl, /var/log, and a safe first-pass workflow.

Scheduled jobs at the wrong hour

Cron uses the host’s configured time rules unless the job or scheduler says otherwise. Check the time zone before rewriting a correct schedule:

timedatectl

The crontab beginner guide covers scheduling, environment differences, and verification.

Package and API errors

Bad time can break signed repository metadata, API requests, session cookies, and distributed-system coordination. It is worth checking the clock before reinstalling half the machine.

A realistic helpdesk workflow

Suppose a Linux VM cannot authenticate to a company service, and its logs appear five minutes behind the identity server.

Capture the current status without changing anything:

timedatectl
date
date -u

Record the configured zone and synchronization flags:

timedatectl show -p Timezone -p NTPSynchronized -p NTP

Identify the time service:

systemctl status systemd-timesyncd --no-pager
systemctl status chronyd --no-pager

Inspect service-specific synchronization data:

timedatectl timesync-status

Or, if Chrony is installed:

chronyc tracking
chronyc sources -v

Check relevant service logs:

journalctl -u systemd-timesyncd -b --no-pager | tail -100
journalctl -u chronyd -b --no-pager | tail -100

Verify DNS, network access, and approved NTP configuration.
Make the smallest approved correction.
Confirm synchronization and retry the original authentication test.
Add the before-and-after offset, service, source, and result to the ticket.

Avoid manually jumping the clock first. A large time change can confuse running software and erase the evidence that explains why synchronization failed.

Set the clock manually only when appropriate

If network synchronization is disabled and a manual change is approved:

sudo timedatectl set-time '2026-07-19 13:30:00'

Verify immediately:

timedatectl
date -u

Manual time setting may fail while automatic NTP is active. More importantly, manually correcting the clock does not fix the reason it drifted. Restore or repair the approved synchronization service when possible.

On production systems, coordinate large corrections with application owners. Databases, monitoring systems, clustered services, and time-based authentication can react badly when time suddenly moves backward or forward.

Hardware clock and RTC warnings

Linux usually stores the hardware real-time clock in UTC:

RTC in local TZ: no

That is the preferred setting for most Linux-only systems. Dual-boot systems sometimes use local RTC for compatibility, but it introduces daylight-saving and cross-OS confusion.

Do not change RTC mode casually. If you have a documented reason:

sudo timedatectl set-local-rtc 0

The 0 configures the RTC for UTC. Confirm platform and dual-boot requirements first.

Virtual machines and containers may not control a traditional hardware clock at all. Containers commonly share the host kernel clock, so the real fix may belong on the host or platform rather than inside the container.

Common timedatectl mistakes

Confusing time zone with wrong time

A correct UTC clock displayed through the wrong zone looks wrong locally. Check both the zone name and UTC time before changing anything.

Assuming NTP active means synchronized

A service can be active while it cannot reach a source. Check System clock synchronized, service-specific status, logs, DNS, and network access.

Changing the clock before capturing evidence

Record status, offsets, service state, and logs first. Otherwise the ticket becomes “time was weird, then we changed it,” which is not especially useful to the next person.

Using vague time-zone abbreviations

Use a named zone such as America/Chicago, not a casual guess like CST. Named zones handle regional daylight-saving rules.

Restarting every time service

Identify which daemon the system is supposed to use. Running competing NTP clients can create a new problem while you are trying to solve the first one.

Forgetting the application layer

Correcting system time does not automatically repair expired sessions, cached tokens, failed jobs, or application state. Retest the original symptom.

Practice time checks without touching production

In a lab, run timedatectl, compare date with date -u, inspect the configured zone, and identify the active synchronization service. Practice reading Chrony or timesyncd status without changing the clock. That is enough to make the next “certificates are broken but only on this server” ticket much less mysterious.

Practice Linux troubleshooting in Shell Samurai to build the habit of checking system state before making changes on a real server.

FAQ

What does timedatectl do in Linux?

timedatectl displays and manages the system time, time zone, hardware-clock mode, and supported network time synchronization settings on systemd-based Linux systems.

How do I check the Linux time zone?

Run timedatectl for full status or timedatectl show -p Timezone --value to print only the configured zone.

How do I enable NTP with timedatectl?

Run sudo timedatectl set-ntp true, then use timedatectl to check whether the NTP service is active and the system clock is synchronized.

Why does timedatectl say NTP is active but the clock is not synchronized?

The client may still be starting, unable to reach its configured source, blocked by DNS or network rules, or managed by a different service. Check the active daemon, its logs, and service-specific status such as timedatectl timesync-status or chronyc tracking.

Should a Linux hardware clock use UTC?

Usually yes. RTC in local TZ: no means the hardware clock is treated as UTC, which avoids many daylight-saving and multi-zone problems. Confirm dual-boot or platform requirements before changing it.