By Jeanelle Horcasitas, Justin Ellingwood, Brian Boucheron and Manikandan Kurup Accurate timekeeping is integral to modern software deployments. Without it, you may encounter data corruption, errors, and other issues that are difficult to debug. Time synchronization can help ensure your logs are being recorded in the correct order, and that database updates are appropriately applied. Ubuntu 24.04 includes built-in time synchronization enabled by default using systemd-timesyncd (often referred to as timesyncd). For more advanced or production use cases, chrony is a modern alternative that offers improved accuracy and reliability. In this article, you will practice common time-related commands, review how the system clock and hardware clock (RTC) work together, verify that Ubuntu’s default systemd-timesyncd service is active, and install and configure chrony as an alternate network time synchronization service. Before starting this tutorial, you will need an Ubuntu server with a non-root, sudo-enabled user and a firewall, as described in this Initial Server Setup with Ubuntu tutorial. To view the time on your server, you will use the command date. Any user can run this command to print out the date and time: Typically, your server will generate an output with the default UTC time zone. UTC is Coordinated Universal Time, the time at zero degrees longitude. While this may not reflect your current time zone, using Universal Time prevents confusion when your infrastructure spans multiple time zones. If you want to change your time zone, you can use the timedatectl command. Ubuntu systems typically default to UTC to avoid ambiguity across distributed systems, but you can configure a local time zone if needed. First, run the following command to generate a list of available time zones: A list of time zones will print to your screen. You can press SPACE to page down, and b to page up. Once you find the correct time zone, make note of it, then type q to exit the list. Next, you can set the time zone using timedatectl set-timezone, replacing the highlighted portion with your desired time zone found in the list. You’ll need to use sudo to make this change: After setting the time zone, you can verify the change by running: The time zone abbreviation will reflect the newly chosen value. As an alternative, Ubuntu also provides an interactive configuration tool: This command opens a text-based interface that allows you to select your geographic region and city. It can be useful if you are unsure of the exact time zone identifier. In addition to setting the time zone, it is helpful to understand how Linux systems manage time internally. There are two clocks to be aware of: The system clock is what your applications and logs use, while the hardware clock keeps time when the system is powered off. While this distinction is useful, it is also important to understand how these clocks interact during normal system operation and time synchronization. When your system boots, the Linux kernel initializes the system clock using the time stored in the hardware clock (RTC). At this point, the system time may not be perfectly accurate, since the hardware clock can drift over time. After boot, a time synchronization service such as systemd-timesyncd or chrony takes over. These services use NTP to query remote time servers and gradually adjust the system clock to match an accurate external reference. This adjustment does not usually happen as an abrupt change. Instead, NTP clients make small, continuous corrections to avoid disrupting running processes that depend on stable time progression. Over time, the relationship between these components works as follows: In most configurations, the hardware clock is not frequently updated after boot. Instead, it acts as a fallback reference. Some systems periodically synchronize the hardware clock with the system clock, but this is secondary to NTP-based synchronization. You can observe this relationship using: Understanding this relationship helps explain why: This model, RTC at boot, kernel clock during runtime, and NTP for correction, is the foundation of timekeeping on modern Linux systems. Most modern Ubuntu systems keep the hardware clock set to UTC, even if the system time zone is configured to a local region. This helps avoid issues related to daylight saving time and ensures consistency across systems. You can check these settings using: Look for the following fields in the output: A typical configuration will look like this: This means that your system is displaying local time, while the hardware clock remains set to UTC. Now that you’ve practiced checking the clock and setting time zones, you can confirm that your time is being synchronized properly in the next section. Previously, most network time synchronization was handled by the Network Time Protocol daemon or ntpd. This service connects to a pool of other NTP servers that provide it with constant and accurate time updates. But now with Ubuntu’s default install, you can use systemd-timesyncd instead of ntpd. systemd-timesyncd works similarly by connecting to the same time servers, but is lightweight and more closely integrated with systemd on Ubuntu. You can query the status of systemd-timesyncd by running timedatectl with no arguments. You don’t need to use sudo in this case: This command prints out the local time, universal time (which may be the same as local time, if you didn’t switch from the UTC time zone), and some network time status information. System clock synchronized: yes reflects that the time is successfully synced, and NTP service: active means that systemd-timesyncd is up and running. If your output shows that NTP service isn’t active, turn it on with timedatectl: After this, run timedatectl again to confirm the network time status. It may take a minute for the sync to happen, but eventually System clock synchronized: will read yes and NTP service: will show as active. While systemd-timesyncd works well for many use cases, some environments require more precise and resilient time synchronization. In these cases, you can use chrony, a modern NTP implementation designed to handle variable network conditions, virtualized environments, and systems that are not always continuously online. Before installing chrony, you need to disable the default systemd-timesyncd service to prevent conflicts between time synchronization services. First, disable network time synchronization so that systemd-timesyncd stops managing your system clock: Next, verify that systemd-timesyncd is inactive by running timedatectl again: In the output, confirm that the NTP service: field reads inactive. Now update your package index so you install the latest available version from your configured repositories: After the installation completes, the chrony service will start automatically. You can confirm that it is running by checking its status: If everything is working, the output will include active (running). To check which time sources your system is using, run: This will display a list of time sources along with their status. The ^* symbol indicates the currently selected source, while ^+ indicates additional candidates. In this output, the first character (^) indicates the source type (NTP), and the second character indicates status. For example, ^* indicates the selected source, while ^- indicates a reachable source that is not currently being used. For more detailed synchronization information, run: This command shows metrics such as system clock offset and frequency adjustments, which help confirm that your system is synchronizing correctly. By default, chrony uses Ubuntu’s NTP pool servers. If you need to use an internal time source or you want to specify a particular set of NTP servers, you can do so by editing chrony’s configuration file. Open the configuration file with a text editor: In this file, locate the pool directive, which tells chrony which server pool to use: You can replace this value, or add additional sources using server lines. For example: The iburst option helps chrony make an initial time correction more quickly when the service starts. After you save your changes, restart the service so it reloads the updated configuration: If you want your system to act as an NTP server for other machines on your network, you can configure chrony to allow incoming client requests. To do this, add an allow directive for the subnet that should be able to query your server: Then restart chrony to apply the change: If you are using a firewall, make sure it allows inbound UDP traffic on port 123, which is the standard port used by NTP. Finally, you can confirm that time synchronization is active: If everything is working correctly, the output will show that the system clock is synchronized and that an NTP service is active. Note: The ntp package is considered a legacy option on modern Ubuntu systems. For most use cases, chrony is recommended due to its improved accuracy and performance, especially in cloud or virtualized environments. systemd-timesyncd will work in most circumstances. There are instances, however, when an application may be sensitive to any disturbance with time. In this case, ntpd is an alternative network time service you can use. ntpd uses sophisticated techniques to constantly and gradually keep the system time on track. Before installing ntpd, you need to turn off systemd-timesyncd in order to prevent the two services from conflicting with one another. You can do this by disabling network time synchronization with the following command: Verify that time synchronization is disabled: Check that your output reads NTP service: inactive. This means systemd-timesyncd has stopped. Now you’re ready to install the ntp package with apt. First, run apt update to refresh your local package index: Then, run apt install ntp to install this package: ntpd will begin automatically after your installation completes. You can verify that everything is working correctly by querying ntpd for status information: ntpq is a query tool for ntpd. The -p flag requests information about the NTP servers (or peers) ntpd is connected to. Your output will be slightly different but will list the default Ubuntu pool servers plus a few others. Remember, it can take a few minutes for ntpd to establish connections. Ubuntu supports multiple time synchronization services, each designed for different use cases. While all three rely on NTP to synchronize system time, they differ in accuracy, complexity, and suitability for modern environments. The following table highlights the key differences: In general, systemd-timesyncd is suitable for simple environments where minimal configuration is preferred. For most production, cloud, or latency-sensitive systems, chrony provides better accuracy and resilience. The ntpd service remains available primarily for compatibility with older systems and is no longer the preferred choice for new deployments. Although time synchronization is usually configured automatically, failures can still occur due to issues in configuration, networking, or service behavior. Because Linux timekeeping depends on coordination between the hardware clock (RTC), the kernel system clock, and an NTP synchronization service, problems can arise at different stages in this process. When troubleshooting, it is helpful to think of timekeeping as a sequence. The system initializes time from the hardware clock during boot, the kernel maintains the system clock during runtime, and an NTP service continuously corrects that clock. If any part of this sequence fails, the system may display incorrect or unstable time. If timedatectl shows System clock synchronized: no, your system clock is not being corrected by an NTP service and may drift over time. This issue typically occurs when no synchronization service is active, or when the service cannot reach external time servers. It may also appear briefly after boot before synchronization has completed. First, check whether a time synchronization service is enabled: If the NTP service field is inactive and you want to use systemd-timesyncd, enable it: If you installed chrony, verify that the service is running: Allow a short period for synchronization to complete, then check the status again. If the NTP service is active but the system clock remains unsynchronized, the service is running but unable to obtain valid time data. This condition is most often caused by network connectivity problems, DNS resolution failures, or firewall restrictions that prevent communication with NTP servers. Test network connectivity: Verify DNS resolution: If either command fails, resolve the underlying network or DNS issue before proceeding. When using chrony, you may find that no usable time sources are available when running chronyc sources. This typically indicates that chrony cannot communicate with its configured servers due to incorrect configuration, network issues, or unavailable upstream servers. Inspect the configuration file: Ensure that valid server or pool entries are present, such as: After making changes, restart the service: Then verify that sources are now available. You may notice that the system time is incorrect immediately after boot but corrects itself shortly afterward. This happens because the system initially reads time from the hardware clock, which may have drifted while the system was powered off. Synchronization begins only after the system has fully started and network connectivity is established. Wait a few minutes for the NTP service to synchronize the system clock. Then verify the status: If the time does not correct itself, ensure that the synchronization service is active and functioning. If the system time is significantly incorrect, synchronization may appear slow or gradual. NTP services typically avoid making large, abrupt changes to the system clock. Instead, they gradually adjust the time to prevent disruptions to running processes. If the time difference is large, manually set an approximate value: Then re-enable synchronization and allow the NTP service to refine the time. If multiple time synchronization services are running simultaneously, the system clock may behave unpredictably. This usually occurs when systemd-timesyncd, chrony, or ntpd are all active at the same time, causing conflicting adjustments. Disable one service before enabling another: Then start your preferred service: Ensure that only one service manages time synchronization. If your system cannot reach external time servers, synchronization will fail. This is typically due to outbound UDP traffic on port 123 being blocked by a firewall or network policy. Allow outbound NTP traffic: Also verify any external restrictions, such as cloud security groups or corporate firewall rules. In virtualized environments, the system clock may drift or behave inconsistently. The guest system’s clock may be influenced by the host or hypervisor, especially if both attempt to manage time independently. Ensure that the host system is properly synchronized and avoid running multiple synchronization mechanisms within the guest. In these environments, chrony is generally preferred because it handles drift more effectively. If the system time resets or behaves inconsistently after reboot, the hardware clock may be misconfigured. This often occurs when the hardware clock is set to local time instead of UTC, or when it has drifted significantly. Check the current configuration: Ensure that RTC in local TZ is set to no. Keeping the hardware clock in UTC avoids issues with daylight saving time and ensures consistent behavior across systems. Ubuntu 24.04 uses systemd-timesyncd as the default time synchronization service. It is a lightweight NTP client that is enabled automatically on most installations and requires little to no configuration. While it is sufficient for basic timekeeping, it does not provide the advanced features or flexibility offered by alternatives like chrony. You can check whether time synchronization is active by running: In the output, look for the fields System clock synchronized and NTP service. If both show positive values (for example, yes and active), it indicates that your system clock is being synchronized with an external time source. systemd-timesyncd is designed to be simple and lightweight, making it suitable for systems that require basic time synchronization with minimal configuration. It runs as part of systemd and is sufficient for many standard use cases. chrony, in contrast, is a more advanced and feature-rich implementation. It provides faster and more accurate synchronization, better handling of network instability, and greater configuration flexibility. For these reasons, chrony is generally preferred for production systems, cloud environments, and systems with stricter accuracy requirements. You can change the system time zone using the timedatectl command. First, list the available time zones: Then set your desired time zone: This updates the system’s time zone immediately, and the change will be reflected in commands such as date and timedatectl. When timedatectl shows System clock synchronized: no, it means that your system clock is not currently being corrected by an NTP service. This can happen if no synchronization service is running, if the service cannot reach external time servers due to network or DNS issues, or if the system has recently booted and synchronization has not yet completed. In most cases, verifying the NTP service status and network connectivity will help resolve the issue. No, it is not recommended to run chrony and systemd-timesyncd at the same time. Both services attempt to control and adjust the system clock, which can lead to conflicting updates and unstable timekeeping. You should disable one service before enabling the other to ensure consistent and predictable synchronization. Most servers synchronize with stratum 2 or stratum 3 time sources, which provide sufficient accuracy for general system and application needs. Lower stratum levels indicate closer proximity to a primary reference clock, but for most environments, stratum 2–3 offers a good balance between accuracy and reliability. Extremely low stratum levels are typically only required in specialized or high-precision systems. Yes, Ubuntu 24.04 supports Network Time Security (NTS) through chrony, provided that both the client and the NTP server support it. NTS adds encryption and authentication to NTP communication, helping protect against spoofing and tampering. However, it requires additional configuration and compatible servers, and it is not enabled by default on most systems. In this article, you used common tools to inspect your server’s time settings, configure a time zone, and understand the relationship between the system clock and the hardware clock (RTC). You also verified that Ubuntu’s default time synchronization (systemd-timesyncd) is working, and you installed and validated chrony as an alternative NTP implementation for more advanced use cases, including customizing time sources and (optionally) allowing client access. To continue learning, you can review the chrony documentation for configuration details such as NTS (Network Time Security), and you can reference the NTP Pool Project to better understand how public time servers are organized. For more Ubuntu-related tutorials, check out the following articles: Thanks for learning with the DigitalOcean Community. Check out our offerings for compute, storage, networking, and managed databases. Learn more about our products This textbox defaults to using Markdown to format your answer. You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link! Hi! I was wondering that if I set my timezone to America/New_York – using the method you described here – if my timezone will automatically update to standard time (EST) in the fall/winter when appropriate and then back to daylight time (EDT) in the spring/summer? Thanks for this content. Won’t a droplet automatically have system time set correctly because it’s getting the time from the server running the droplet’s hypervisor? If you’re behind a firewall or proxy, make sure UDP port 123 is open for NTP Please complete your information! Get paid to write technical tutorials and select a tech-focused charity to receive a matching donation. Full documentation for every DigitalOcean product. The Wave has everything you need to know about building a business, from raising funding to marketing your product. Stay up to date by signing up for DigitalOcean’s Infrastructure as a Newsletter. New accounts only. By submitting your email you agree to our Privacy Policy Scale up as you grow — whether you're running one virtual machine or ten thousand. Sign up and get $200 in credit for your first 60 days with DigitalOcean.* *This promotional offer applies to new accounts only.