Contact
Site: US UK AU |
Nexcess Blog

Adventures in Timezones: How a Server’s Timezone Can Go Wrong

June 24, 2019 0 Comments RSS Feed

How a Server’s Timezone Can Go Wrong

For the average American living in Chicago, being able to tell the time in New York is easy. Simply take the time in Chicago and add one hour: 10am becomes 11am.

Yet timezones becomes more complicated when geopolitics are involved, and for any tasks that involve time processing, knowledge of the correct timezone is vital.

Keep reading to find out three of our top ways a server’s timezone can go wrong and how you can fix it.

How Do Timezones go Wrong?

So you know what time zones are and you’ve configured each and every one of your servers to reflect them correctly. For one client in the UK you’ve set the server to GMT +0, for another in Russia you’ve set it to UTC +4, and for another in California you’ve set it to GMT -8 (you think).

Congratulations, you’ve managed to set up time zones that reflect where your clients are based. But you’ve made a mistake… a few, in fact. You’re clients are quickly back on the phone asking why you selected that timezone and telling you that it needs to change ASAP.

So, where did you go wrong?

You Forgot Daylight Savings

Imagine you’re setting up a server and you get to a point where you need to set a timezone. “Well Michigan is (almost completely) in the eastern timezone”, you think to yourself, “and it’s March 27th, so I’ll set the timezone to EDT.” If you set the timezone to ‘EDT’, this would work fine… Until November 4th.

That’s because this is when Daylight Saving Time (DST) ends. At this point, your server would be off by 1 hour until DST starts again. If you had instead set your timezone to ‘America/Detroit’, it would have switched for DST at the right time and would switch back again too. This is why operating system installers often have you choose a location instead of a timezone directly.

Some Timezones Aren’t What They Appear

Remember daylight savings when you set a timezone on a serverA client requests the timezone be set to ‘GMT-8’, which means 8 hours behind UTC/GMT. (Roughly corresponds to British Columbia, California, most of Nevada, some of Mexico.) You happily go off and set the time zone to the IANA time zone database special administrative zone  (wow, what a mouthful) of ‘Etc/GMT-8’. You then happily go about your day.

That is until the client frantically rushes to tell you you’ve completely goofed up and set the timezone to GMT+8, the opposite of what they wanted. (This roughly corresponds to east Asia, and Fun fact: this is the most populous timezone in the world).

You double check and see to which file /etc/localtime is a symbolic link. You see /usr/share/zoneinfo/Etc/GMT-8, which appears correct. You scratch your head for a while.

Eventually you venture far enough down the rabbit hole that you find out that the ‘Etc/GMT’ time zones in the IANA timezone database have their sign switched due to legacy POSIX reasons, just like every weird thing in the wonderful world of Linux. You switch the timezone to ‘Etc/GMT+8’ and update. All is good with the world.

Timezones Reflect Geopolitics

Geopolitics can affect timeszones making them uncertainThe year is 2013. In between frequent bouts of the harlem shake, you field a client request to update the server to the same timezone as Moscow. Being very geopolitically savvy, you knew right off the bat that Russia switched to “permanent daylight saving time” in 2011 and the timezone of Moscow would be UTC+4. Permanent sure does sound like forever to you, so you pat yourself on the back and call it good.

BUT YOU’RE WRONG.

Russia switched to, ahem, permanent non-daylight saving time (?) in October 2014, making the correct timezone for Moscow UTC+3 “permanently” from that point on. Since you used UTC+4, the servers time became off in 2014 and the client had to put in a new ticket to adjust it.

If you had used ‘Europe/Moscow’ instead, the timezone would have been correctly adjusted in 2014 due to updates to the ‘tzdata’ package. This package contains the IANA timezone database and is updated for administrative and geopolitical changes as time goes on.

Changing Timezone to Location

Instead of changing the servers to a specific named time zone, we recommend setting time to a specific location. This helps to avoid the pitfalls and issues outlined above.

One of the most popular timezone databases is called the tz database. Within the database, different locations have different names depending on Area/Location. For instance, America/Detroit, Europe/London, etc.

Instead of going to a UTC/GMT offset such as GMT+8, databases like the tz database account for geopolitical and other changes around the world which allows you to set the timezone to a location. This means that as long as you’ve set your location correctly, then your timezone will never go wrong… probably.

Posted in: Nexcess