Ensuring your server’s time zone is correctly set is important for various operations and logging. This guide will walk you through the steps to change or verify the time zone on CentOS servers and address common related issues.

For CentOS 4, 5, and 6

To change the time zone on these versions of CentOS, you will work with the system’s timezone file.

Backup the current time zone file: It’s good practice to back up the existing /etc/localtime file.

mv /etc/localtime /etc/localtime.bak

Create a symbolic link to the desired time zone: You will link /etc/localtime to the appropriate timezone file located in /usr/share/zoneinfo/. For example, to set the time zone to America/Detroit, you would use:

ln -s /usr/share/zoneinfo/America/Detroit /etc/localtime

Remember to replace “America/Detroit” with the directory and filename corresponding to your desired time zone from /usr/share/zoneinfo/.
Edit the clock configuration file: Depending on the specific CentOS version, you may also need to edit the /etc/sysconfig/clock file. This file should contain a line specifying the time zone using the pattern:

ZONE="directory/filename"

Again, replace “directory/filename” with the location from /usr/share/zoneinfo/.

This change to the system’s time zone is instantaneous.

To verify that the server is using the correct time after making these changes, you can run:

date

After changing the system time zone, many services and software applications that capture date and time information will need to be restarted for the change to take effect. This list is likely not comprehensive, but covers many important services you might notice. Here are some common ones and how to restart them:

Apache (httpd): /etc/init.d/httpd stop; /etc/init.d/httpd start
rsyslog/syslogd: /etc/init.d/rsyslog restart; /etc/init.d/syslogd restart (Different CentOS versions use different variants on syslog)
NTP Daemon (ntpd): /etc/init.d/ntpd restart
Cron Daemon (crond): /etc/init.d/crond restart
MySQL: /etc/init.d/mysql restart

You will also likely want to review the section on PHP below, as PHP pulls its timezone information from a different location.

For CentOS 7

CentOS 7 uses the timedatectl command to manage time settings, including the time zone.

List available time zones: To find the correct name for your desired time zone, run:

timedatectl list-timezones

Set the time zone: Once you have identified the correct time zone from the list, use the set-timezone command. For example, to set the time zone to America/Detroit:

timedatectl set-timezone America/Detroit

Remember to replace “America/Detroit” with the time zone you wish to use from the list.

This change is instantaneous.

To check your work and ensure the server is using the correct time after setting the time zone, you can run:

timedatectl status

Similar to earlier versions, a number of other services and software capture date and time information when they are started and will likely need to be restarted for the changes to take effect. This list is likely not comprehensive, but covers many important services you might notice. Here are some common ones and how to restart them using systemctl:

rsyslog: systemctl restart rsyslog
Apache (httpd): systemctl stop httpd; systemctl start httpd
NTP Daemon (ntpd): systemctl restart ntpd
Cron Daemon (crond): systemctl restart crond
MySQL: systemctl restart mysqld

You will likely also want to view the section on PHP below, as PHP pulls its timezone information from another location.

Where to Find a List of Time Zones

The lists of available time zones, such as those found in the /usr/share/zoneinfo/ directory or displayed by the timedatectl list-timezones command, are derived from the IANA Time Zone Database (often called the tz database or zoneinfo database).

For a comprehensive list of zones included in this database, you can refer to resources outside of this documentation. For example, a widely referenced list can be found on Wikipedia.

List of tz database time zones: https://en.wikipedia.org/wiki/List_of_tz_database_time_zones

Addressing PHP Time Zones

It’s important to note that not all software on the server will automatically reflect the system time zone change. PHP, for instance, often gets its time zone information from the date.timezone directive within its configuration file, php.ini.

You will need to locate your php.ini file and edit the date.timezone line to specify the correct time zone. The format for this directive is:

date.timezone="directory/filename"

As described in the CentOS 4,5,6 section above, “directory/filename” refers to the directory and file name of the timezone file within /usr/share/zoneinfo/.

Unexpected Time Zone Changes

If a server is experiencing instances where the time zone is suddenly and unexpectedly changing, it’s likely related to updates to glibc. The RPM package for glibc controls the /etc/localtime file, which means that updates to glibc have the potential of modifying /etc/localtime. If an unexpected timezone change has occurred, check /var/log/yum.log to see if it correlated with a recent update to glibc.

If this is the case, it’s likely that /etc/localtime was modified without either /etc/sysconfig/clock being updated (On earlier versions of CentOS) or timedatectl being ran (On CentOS 7). Follow the steps outlined above appropriate for the OS that you’re working with in order to resolve this.

What if the Server Time is Still Wrong?

If the server is showing the wrong time in spite of the time zone being correct, it’s likely that it just needs to be pointed to our NTP server. You can point it to Liquid Web’s NTP server to correct the time:

Stop the NTP service:

service ntpd stop

Manually synchronize time with the Liquid Web NTP server:

ntpdate time.liquidweb.com

The second command should provide output similar to this, indicating a successful time adjustment: 7 Aug 01:15:55 ntpdate: step time server 209.59.139.28 offset -14400.147754 sec
Start the NTP service:

service ntpd start

Troubleshooting ntpdate Errors:

Occasionally, the ntpdate time.liquidweb.com command might fail with “Operation not permitted” errors:

7 Aug 05:12:40 ntpdate: sendto(xyz.liquidweb.com): Operation not permitted
7 Aug 05:12:44 ntpdate: no server suitable for synchronization found

If you encounter these errors, it’s likely that UDP port 123 (used for NTP) is blocked by a firewall, either incoming or outgoing. Opening these up, and the command should run as expected.

Was this article helpful?

Thank you for your input.

Thank you for your feedback.