Updated: September 1, 2016
This seems to be a rather trivial topic, defined by a rather trivial question. But then, it is not really. Say you have a host that uses a specific timezone, and now you want to start using a different one. What do you do at this point? How do you reconfigure the system without making extensive, painful modifications?
I asked myself this question while fiddling with a bunch of CentOS servers, and then after some online hunting and reading, I realized that most if not all guides on this topic have a singular, copy & paste approach that is neither 100% foolproof nor correct. For that reason, you are not enjoying this howto. Follow me please.
Note: Image credits, Kerem Yucel, freeimages.com.
The number of methods is three, and three is the number of methods. The way you approach this issue will depend on what particular distribution you choose. Of course it cannot be simple, Gods of the Web forbid, as we need fragmentation and variety among different distros. Let's start with what everyone is telling you. First, the easier way to check your timezone is by running the date command:
The timezone information is universally kept under /etc/localtime. On more modern systems, this file is merely a symbolic link to text-based timezone files stored under /usr/share/zoneinfo/<region>/<city>.
ls -l /etc/localtime
lrwxrwxrwx. 1 root root 35 Jan 16 22:10 /etc/localtime -> ../usr/share/zoneinfo/Europe/Oslo
However, on some distributions, including say CentOS, the localtime file is in binary format, identified as TZ data files. You cannot directly read, write or manipulate these files.
The modern solution of changing a timezone becomes a simple exercise of changing the symbolic link. You might need to use the -f flag to force the new link:
ln -sf /usr/share/zoneinfo/<region>/<city> /etc/localtime
But this is not ideal for some (mostly older) systems. Sooooo ...
So what do we do instead?
The right approach is to update the timezone using the tzselect tool. This tool should be available on pretty much every Linux distro. Some systems also offer a GUI equivalent, like for instance the Red Hat system-config-date, bit it requires a display to work correctly.
Run the tool, select the right region, then select the right city. Approve your choice. The change is immediate. However, we are still not done. There are several other things you should do.
The next step is to actually push the updates:
Moreover, we also need to take care of the hardware clock, to make sure that you don't get any weird conflicts, especially during boot up and shutdown time. To wit, if present, the file /etc/sysconfig/clock controls the system clock and contains the information about your timezone, but it does not affect it. The data will be parsed and read by system-config-date utility. To make things a little more confusing, it may contain the following four directives, but only the ZONE one is mandatory, as the others will be set to the specific distro default values.
UTC is important, as it determines if your hardware clock is set to universal time or local time. The other two are less important at this point. The last directive, ZONE contains information stored in the same format like the timezone files: ZONE="<region>/<city>". You should match this to whatever you selected using tzselect, e.g. Europe/Oslo.
Once this file is up to date, you need to consider rebooting or restarting your applications and services. Most standard Linux applications should be fine, but some might have odd ways of picking up the time/date, and they may only do it when launched. Moreover, Java applications will have their own timezone info files. Last but not the least, you may want to consider using NTP, to make sure the time is set correctly on your system.
There we go. I never thought a trivial topic could be so complex, but it turns out that time management is a finicky one, which is why I dedicated some time [sic] to write a tutorial. It is important to note the little details and nuances, and make sure all the system files correctly reflect your choices, to avoid weird application problems and inconsistencies.
Changing timezones does not guarantee miracles, and some of your stuff may not work correctly, or it may use its own ways of interpreting time. This is why you should be careful, and avoid making manual changes. Always go through system tools, as they could update an obscure little file here and there that you do not quite expect. The info from the Web is true, but then, there's a lot more to be known about how to manage your timezones. 'Twas fun for me, was it for you?