One of the seemingly simple things that can be troublesome to get a grasp on is dealing with time zones on your devices and servers. Oftentimes, there can be a lot of discrepancy. These four tips will help you keep your servers on time and also help you when dealing with servers set to time zones not native to you.
1. System Updates Also Include Time Zone Updates
Oftentimes, a country, state, province, or even a locality or city can change their time zone rules, both for offset and for any seasonal changes (daylight savings). Microsoft and various Linux vendors note these and release updates for their software that accounts for this. It is considered good practice to keep track of updates, especially for time zones
2. Check-in Regularly
Even if you keep your time zone data up to date, you still need to make sure your server is keeping time. Thanks to common internet connectivity, this is easily handled via the Network Time Protocol (NTP). Major OSes often have an NTP client that can connect to NTP servers and obtain precise time data to keep their clocks synchronized. In Windows, this is done automatically, and if the server is connected to a Domain Controller, then it will receive updates from the controller. In Linux, the client of choice is rdate. You can easily setup a cronjob (scheduled task) to update against a NTP server:
0 0 * * * rdate -s rdate.darkorb.net
When put in the root crontab (crontab -e as root user), it will contact NTP server rdate.darkorb.net at midnight every day.
3. Changing Time Zones
By default, our infrastructure and deployed servers use the same time zone as our corporate headquarters in Chicago, IL, which is US Central Time. This means that the time zone offset from UTC (or GMT) would be:
UTC-6 (Normal)
UTC-5 (Daylight Savings Time)
If you’re curious, here are the offsets for the locations of our datacenters outside Chicago:
Phoenix:
UTC-7 (Note: Daylight savings is never observed in the US state of Arizona)
Amsterdam:
UTC+1 (Normal)
UTC+2 (Daylight Savings Time)
If you need to change your time zone in Windows, you can do so in the Time/Date settings in the control panel. Linux over the command line is trickier, but still easy to do. In most Linux/Unix systems, there is a file called /etc/localtime that is ‘linked’ to the proper time zone file. Time zones are stored in /usr/share/zoneinfo. For example, if you wanted to change to US Eastern Time, you would run this command:
ln -sf /usr/share/zoneinfo/America/New_York /etc/localtime
4. Calculating Time Zone Differences
One of the biggest headaches is trying to figure out what time it is in a time zone you are not familiar with. There is actually a mathematical formula to determining what the time is in a remote time zone:
“Local Time” – “UTC offset for Local Time” = “Remote Time” – “UTC offset for Remote Time”
Since you know everything but the remote time, you can plug in the rest and solve for the variable. Hopefully, we can recall our high school Algebra here. To keep things straight, we will also use 24 hour time. Let’s work an example if it is 8 PM (2000 hours) in Chicago (UTC-5) currently and you want to know what time it is in Amsterdam (UTC+2):
2000 – (-500) = X – (+200)
2000 + 500 = X – 200
2500 = X – 200
2700 = X
Since 24 hour time is measured in base 2400 and not base 10 like decimal, this means that it is 3 AM (0300) in Amsterdam on the next day.
With this information, you are sure to get a better handle on managing time zones on your servers, whether it is here at INAP or halfway across the world.
Updated: January 2019
