Configuring Time and Date Settings

At its simplest, a computer keeps track of time using a hardware clock — a small battery-powered chip on the motherboard that continues ticking even when the machine is powered off. This is often called the Real-Time Clock (RTC). When the operating system boots, it reads the RTC and uses that value to set its system clock, which is the software-based clock that the kernel uses for all time-stamping operations. The problem is that the RTC is not very accurate — it can drift by several seconds per day depending on temperature and the quality of the crystal oscillator.

To solve this, modern Linux systems use Network Time Protocol (NTP) to synchronise the system clock with highly accurate remote time servers. NTP is a protocol — a set of rules — that allows a client (your server) to ask a server (a time server) for the current time, then calculate the difference and adjust the system clock accordingly. The adjustment is not done in one big jump because that could cause chaos for applications tracking elapsed time. Instead, NTP slews the clock — gradually speeding it up or slowing it down until it matches the reference.

The Red Hat Enterprise Linux (RHEL) environment uses two primary tools for time management: timedatectl and chrony.

timedatectl is a command-line utility that is part of the systemd family. Use it to display the current time, date, time zone, and synchronisation status. You can also use it to set the time zone (timedatectl set-timezone Europe/London), enable or disable NTP synchronisation (timedatectl set-ntp true), and even manually set the system date and time (timedatectl set-time "2025-03-15 14:30:00") if NTP is disabled. On the EX200 exam, you will be expected to read the output of timedatectl status to determine whether NTP is active and which time zone is configured.

chrony is the default NTP implementation on RHEL 8 and later. It consists of two components:

The configuration file for chrony is /etc/chrony.conf. In this file, you specify which NTP servers the system should query. For example, a common pool is pool.ntp.org, which directs your server to a group of publicly available time servers. You can also add multiple server directives for redundancy. Inside chrony.conf, you might see lines like:

server 0.rhel.pool.ntp.org iburst server 1.rhel.pool.ntp.org iburst

The iburst option tells chronyd to send a quick burst of queries when the service starts, so that it can synchronise rapidly. After that, chronyd uses a sophisticated algorithm to continuously measure the offset (the difference between the system clock and the NTP server) and the drift rate (how fast the clock is gaining or losing time). It then applies small corrections to keep the clock accurate to within a few milliseconds.

Why does all this matter? Three reasons dominate the exam objectives. First, authentication. Many protocols like Kerberos require that the timestamps on client and server be within a small window — often five minutes. If the clocks differ by more than that, authentication fails silently, and users cannot log in. Second, logging and forensic analysis. If you are investigating a security incident, you need logs from multiple servers to line up perfectly. A clock that is off by even a minute can make a timeline meaningless. Third, scheduled tasks. Cron jobs and systemd timers rely on the system clock to know when to run. If the clock is wrong, backups might run in the middle of the day, or maintenance scripts might never fire.

On the EX200 exam, you will need to demonstrate these skills:

The exam will likely present you with a scenario where a server's time is incorrect, and you must diagnose the problem, fix the time zone, or configure NTP synchronisation. The traps typically involve confusion between setting the date manually versus enabling NTP — they are mutually exclusive operations. Another common trap is forgetting that changes to /etc/chrony.conf require a restart of the chronyd service to take effect. Finally, remember that timedatectl set-timezone affects only the system clock's time zone; it does not change the underlying UTC time stored by the hardware clock.

A financial services company runs a fleet of 200 web servers that process credit card transactions. The compliance auditor requires that all server clocks be synchronised to within 500 milliseconds of a national time standard. One day, a junior administrator accidentally changes the time zone on a database server from UTC to America/New_York, not realising that the app server communicates with it using UTC timestamps. Suddenly, all transactions from the past hour appear to have been made in the future, causing the fraud detection system to flag thousands of legitimate orders.

Here is how a senior systems administrator would diagnose and fix this mess:

Step one: Run timedatectl on the database server to check the current time zone and NTP status. The output shows "Time zone: America/New_York (EST, -0500)" and "NTP service: inactive". The administrator immediately recognises the problem — the time zone was changed and NTP was turned off.

Step two: Correct the time zone to UTC using timedatectl set-timezone UTC. Then enable NTP synchronisation with timedatectl set-ntp true. This restarts the chronyd service automatically on most RHEL systems.

Step three: Verify that chronyd is running and talking to a time server. The administrator runs chronyc sources -v. The output should show one or more lines with a "^*" prefix, which indicates a synchronised source. If it shows "^?" (meaning no response), the administrator checks the network connectivity and the /etc/chrony.conf file to ensure that valid NTP servers are listed.

Step four: Check the actual offset using chronyc tracking. This command shows the current difference between the system clock and the reference server, measured in microseconds. If the offset is larger than a few hundred microseconds, the administrator waits for chronyd to slew the clock back into alignment. If the offset is extremely large (several seconds), a manual adjustment might be necessary.

Step five: Synchronise the hardware clock with the corrected system clock using hwclock --systohc. This writes the system time to the RTC so that even after a reboot, the clock is correct.

Step six: Check the system logs in /var/log/messages or use journalctl to confirm that chronyd has logged successful synchronisation events.

After these steps, the database server is back in sync, the fraudulent order alerts stop, and the compliance audit passes. The real-world lesson is that time configuration is not a set-it-and-forget-it task — it requires regular verification, and one careless change can cause cascading failures across the entire infrastructure.