Accurate timekeeping is one of those things you never think about until it breaks. When certificates start failing, cron jobs fire at the wrong hour, or log timestamps stop making sense, you realize just how much of your infrastructure depends on getting the clock right. This guide covers everything the LPIC-1 102 exam expects you to know about managing date and time on Linux systems, with practical examples you can use on production boxes today.
Hardware Clock vs System Clock
Linux maintains two separate clocks, and understanding the difference between them is fundamental to time management on any system.
The hardware clock (also called the real-time clock or RTC) is a battery-backed clock on your motherboard. It keeps ticking even when the machine is powered off. The kernel reads this clock during boot to set an initial time. The device node for the hardware clock is /dev/rtc or /dev/rtc0.
The system clock (also called the software clock) is maintained by the running kernel. Once the system is up, the kernel tracks time independently using its own tick counter. All userspace programs, log entries, and scheduled tasks reference the system clock.
The hwclock command lets you interact with the hardware clock directly. You need root privileges for most operations.
Read the hardware clock:
sudo hwclock --showSet the hardware clock from the current system time:
sudo hwclock --systohcSet the system clock from the hardware clock:
sudo hwclock --hctosysThe hardware clock can store time in either UTC or local time. On systems that dual-boot with Windows, you may find the RTC set to local time, since Windows expects that by default. On a Linux-only system, storing the RTC in UTC is the standard and recommended approach. You can explicitly set this with hwclock --systohc --utc or hwclock --systohc --localtime.
timedatectl: The Modern Time Management Tool
On any systemd-based distribution (which covers nearly all current enterprise and desktop Linux), timedatectl is your primary tool for viewing and configuring time settings. It replaced the patchwork of older commands with a single, consistent interface.
View the current time configuration:
timedatectlThe output shows local time, UTC time, the RTC time, your timezone, and whether NTP synchronization is active. This single command gives you a complete picture of the time state on the system.
List all available timezones:
timedatectl list-timezonesSet the timezone to US Eastern:
sudo timedatectl set-timezone America/New_YorkManually set the date and time (this disables NTP sync):
sudo timedatectl set-time "2026-03-19 14:30:00"Enable NTP synchronization:
sudo timedatectl set-ntp trueDisable NTP synchronization:
sudo timedatectl set-ntp falseWhen you enable NTP with timedatectl set-ntp true, it activates the systemd-timesyncd service (or whichever NTP service is installed). When you disable it, the system relies on the hardware clock and manual time setting only.
systemd-timesyncd: The Simple NTP Client
systemd-timesyncd is a lightweight SNTP (Simple Network Time Protocol) client built into systemd. It ships with every systemd-based distribution and handles the most common use case: keeping a client machine synchronized with upstream NTP servers. It does not function as an NTP server itself, which is an important distinction.
For workstations, containers, virtual machines, and servers that simply need accurate time, systemd-timesyncd is perfectly adequate. It uses less memory and fewer resources than a full NTP daemon.
Check the service status:
systemctl status systemd-timesyncdView detailed synchronization information:
timedatectl timesync-statusThis shows the server you are synced to, the polling interval, the measured offset, and the delay. It is the quickest way to confirm that time synchronization is actually working.
The configuration file lives at /etc/systemd/timesyncd.conf. The default configuration usually points to your distribution’s NTP pool. To customize it, edit the file and specify your preferred NTP servers:
[Time]
NTP=0.pool.ntp.org 1.pool.ntp.org 2.pool.ntp.org 3.pool.ntp.org
FallbackNTP=ntp.ubuntu.comAfter editing the configuration, restart the service:
sudo systemctl restart systemd-timesyncdThe NTP= line defines your primary servers. The FallbackNTP= line provides backup servers in case the primary ones are unreachable. Distributions typically set their own fallback servers, so you only need to override this if you have specific requirements.
chrony: The Advanced NTP Solution
When you need more than a basic SNTP client, chrony is the go-to solution on modern Linux systems. It replaced ntpd as the default NTP implementation on RHEL/CentOS 8+, Fedora, and many other distributions. Chrony handles both client and server roles, converges faster after boot, and works better on systems with intermittent network connectivity or virtual machines where the clock can jump around.
Install chrony on Debian/Ubuntu:
sudo apt install chronyInstall chrony on RHEL/Fedora:
sudo dnf install chronyEnable and start the service:
sudo systemctl enable --now chronydNote that installing chrony will typically disable systemd-timesyncd automatically, since only one NTP client should run at a time.
The main configuration file is /etc/chrony.conf (or /etc/chrony/chrony.conf on Debian-based systems). A basic client configuration looks like this:
pool 2.pool.ntp.org iburst
makestep 1.0 3
rtcsync
driftfile /var/lib/chrony/driftThe pool directive tells chrony to use the NTP pool. The iburst option sends a burst of requests on initial startup to get synchronized faster. The makestep directive is important: it tells chrony to step (jump) the clock if the offset is larger than 1.0 second, but only during the first 3 clock updates after startup. After that, chrony will gradually slew the clock. This prevents large time jumps on a running system while still allowing fast correction at boot. The rtcsync directive tells chrony to periodically write the system time back to the hardware clock.
Check which NTP sources chrony is using:
chronyc sourcesFor a more verbose view with statistics:
chronyc sources -vCheck the current synchronization status:
chronyc trackingThe tracking output tells you which server is currently selected, the system clock offset, the frequency error (drift rate), and the root delay/dispersion to the reference clock. Pay attention to the “Leap status” field. It should show “Normal” when everything is working correctly.
To configure chrony as an NTP server for your local network, add an allow directive to the configuration:
allow 192.168.1.0/24This permits clients on the 192.168.1.0/24 subnet to query this machine for time. Restart chronyd after making configuration changes.
ntpd: The Legacy NTP Daemon
The classic ntpd (from the ntp.org reference implementation) is the original NTP daemon for Unix and Linux systems. While chrony has largely replaced it on modern distributions, ntpd still appears on the LPIC-1 exam objectives and remains in use on older systems.
The configuration file is /etc/ntp.conf. A typical configuration specifies upstream servers:
server 0.pool.ntp.org iburst
server 1.pool.ntp.org iburst
server 2.pool.ntp.org iburst
server 3.pool.ntp.org iburst
driftfile /var/lib/ntp/ntp.driftThe ntpq command is used to query the ntpd daemon:
ntpq -pThis displays the peer list. The server marked with an asterisk (*) is the one currently selected as the synchronization source. A plus sign (+) indicates a candidate server. Look at the “offset” and “jitter” columns to assess time accuracy.
If the clock is way off, ntpd will refuse to sync by default (it gives up if the offset exceeds 1000 seconds). You can force an initial sync with ntpdate before starting ntpd, though ntpdate is deprecated in favor of ntpd -gq for a one-shot correction.
Keep in mind that you should only run one NTP client at a time. Running ntpd alongside chronyd or systemd-timesyncd will cause conflicts and unpredictable behavior.
The date Command
The date command is one of the oldest and most versatile tools for working with time on the command line. It can display the current time, set the system clock, and format time output in virtually any way you need.
Display the current date and time:
dateDisplay the date in a custom format:
date "+%Y-%m-%d %H:%M:%S"Here are the most commonly used format specifiers you should know for both the exam and daily work:
%Y– Four-digit year (2026)%m– Month as two digits (01-12)%d– Day of the month (01-31)%H– Hour in 24-hour format (00-23)%M– Minute (00-59)%S– Second (00-59)%Z– Timezone abbreviation (UTC, EST, etc.)%s– Unix epoch timestamp (seconds since 1970-01-01 00:00:00 UTC)%A– Full weekday name (Thursday)%B– Full month name (March)
Display the date in UTC regardless of the system timezone:
date -uShow the Unix epoch timestamp:
date +%sSet the system time manually (requires root):
sudo date -s "2026-03-19 14:30:00"Display a date relative to the current time (GNU date):
date -d "+3 days"
date -d "last Friday"
date -d "2 hours ago"The -d flag is extremely useful in scripts for calculating future or past dates without manual arithmetic.
The cal Command
The cal command displays a simple calendar in your terminal. It is a quick reference tool that shows up occasionally on exams.
Show the current month:
calShow the entire current year:
cal -yShow a specific month and year:
cal 3 2026The ncal variant displays the calendar in a different layout with days as rows instead of columns. Both commands are part of the util-linux or bsdmainutils package depending on your distribution.
Timezones on Linux
Linux stores timezone data in the /usr/share/zoneinfo directory. This directory contains a hierarchy of binary timezone files organized by region and city. For example, /usr/share/zoneinfo/America/Chicago contains the rules for US Central time, including all historical daylight saving time transitions.
The system-wide timezone is determined by the /etc/localtime file, which is typically a symlink to the appropriate file in /usr/share/zoneinfo. You can check where it points:
ls -l /etc/localtimeOn many distributions, the timezone name is also stored in /etc/timezone as a plain text string like America/New_York.
Set the system timezone using timedatectl (the recommended method):
sudo timedatectl set-timezone Europe/LondonYou can also set the timezone manually by creating the symlink yourself, though timedatectl is preferred:
sudo ln -sf /usr/share/zoneinfo/Asia/Tokyo /etc/localtimeIndividual users can override the system timezone for their own sessions using the TZ environment variable. This does not require root privileges and does not affect other users:
export TZ="America/Los_Angeles"
dateYou can also use TZ inline for a single command:
TZ="Asia/Kolkata" dateThis is handy when you need to quickly check what time it is in another timezone without changing your system settings.
NTP Pool Servers
The NTP Pool Project (pool.ntp.org) is a large cluster of volunteer-run time servers that provides reliable NTP service to millions of clients worldwide. When you configure a pool address like 0.pool.ntp.org, DNS returns a different set of NTP server IP addresses on each query, distributing the load across many servers.
The pool is organized into zones. You can use a vendor-specific or region-specific zone for better results:
pool.ntp.org– Global pooleurope.pool.ntp.org– European serversnorth-america.pool.ntp.org– North American servers0.ubuntu.pool.ntp.org– Ubuntu vendor zone0.centos.pool.ntp.org– CentOS vendor zone
Most distributions ship with their own vendor zone preconfigured. Using the vendor zones is good practice because it allows the NTP Pool Project to track which distributions are generating traffic and allocate resources accordingly.
In environments with strict security policies or air-gapped networks, you will need to run your own internal NTP servers. In that case, configure one or two machines to sync with the public pool (or a GPS clock), and point all other internal machines at those servers. Chrony makes this straightforward with its allow directive.
Troubleshooting Time Issues
Time problems tend to be subtle and can cause cascading failures. Here are the most common issues and how to diagnose them.
Clock Drift
All hardware clocks drift over time. A cheap motherboard clock might gain or lose several seconds per day. This is exactly why NTP exists. If you notice that a machine’s clock is consistently off, first verify that NTP synchronization is running:
timedatectlLook for “NTP service: active” and “System clock synchronized: yes” in the output. If NTP is active but the clock is still drifting, check the actual sync status with chronyc tracking or timedatectl timesync-status to see if the client is actually reaching its upstream servers.
NTP Not Syncing
If NTP is enabled but the clock is not synchronized, work through these checks in order:
Verify DNS resolution is working (NTP pool hostnames need to resolve):
host 0.pool.ntp.orgCheck that UDP port 123 is not blocked by a firewall:
sudo ss -ulnp | grep 123Make sure only one NTP client is running. Having both chronyd and systemd-timesyncd active at the same time will cause problems:
systemctl is-active chronyd systemd-timesyncdIf the system time is extremely far off (hours or more), chrony’s makestep directive should handle the initial correction. For ntpd, you may need to stop the service, run ntpd -gq for a one-time correction, then start it again.
Timezone Mismatch
If timestamps in logs or applications look wrong but the system clock is accurate in UTC, you almost certainly have a timezone issue. Check the current timezone with timedatectl and compare it to what your applications expect. Remember that the TZ environment variable in a user’s session or a service’s unit file can override the system timezone. Also check /etc/localtime to verify the symlink points to the correct zoneinfo file.
On dual-boot systems, a common gotcha is the RTC being set to local time for Windows compatibility. When Linux boots and interprets the RTC as UTC (its default assumption), you end up with the system clock offset by your timezone’s UTC difference. Use timedatectl set-local-rtc 0 to store UTC in the RTC (preferred), or timedatectl set-local-rtc 1 if you must keep local time for Windows compatibility.
LPIC-1 102 Exam Mapping
This material maps to LPIC-1 Exam 102, Topic 108: Essential System Services, specifically objective 108.1: Maintain system time. The exam weight is 3.
Key knowledge areas tested:
- Set the system date and time
- Set the hardware clock to the correct time in UTC
- Configure the correct timezone
- Basic NTP configuration using ntpd, chrony, or systemd-timesyncd
- Knowledge of the pool.ntp.org service
- Awareness of the
timedatectlcommand
Files and commands you should be comfortable with for the exam:
/usr/share/zoneinfo//etc/timezone/etc/localtime/etc/ntp.conf/etc/chrony.conf(or/etc/chrony/chrony.conf)/etc/systemd/timesyncd.confdatehwclocktimedatectlntpd,ntpqchronycpool.ntp.org
When studying for the exam, focus on understanding when to use each tool rather than memorizing every option. Know the difference between stepping and slewing the clock, understand why only one NTP service should be active, and be able to read the output of ntpq -p, chronyc sources, and timedatectl. Practice setting timezones both with timedatectl and by manipulating /etc/localtime directly, since the exam may test either approach.
Summary
Getting time right on Linux comes down to three layers: the hardware clock that persists across reboots, the system clock the kernel maintains while running, and NTP synchronization that keeps everything accurate. For most systems, systemd-timesyncd handles NTP synchronization out of the box with zero configuration. When you need an NTP server or more control over synchronization behavior, switch to chrony. Reserve ntpd knowledge for legacy systems and exam preparation. Use timedatectl as your primary interface for viewing and configuring time settings, and know the date and hwclock commands for those situations where you need direct control.
