Explaining Time Zones and Best Practices for Configuring Time on Servers
When asked, the average East Coast-living American could regurgitate the time on the Pacific coast with ease. Current time minus three hours. 11 AM become 8 AM and 5 PM becomes 2 PM. The reverse obviously applies for those living on the West Coast calculating current time on the East Coast.
We take time zones and the simple plus/minus calculation for granted considering how important they are to scheduling events on anything more than a local scale. Businesses operate on a national and global scale more frequently than ever, today. Let’s look at how time zones came about, how technology handles time zones, and ways to avoid time zone issues in software development and infrastructure management.
The Beginning of Time (Zones) and Daylight Saving Time
(Ed. note: Skip this section if you want to avoid the history lesson!)
Time zones are a relatively new invention in the annals of history. Around the time of the Industrial Revolution, timekeeping became more important. Why?
Railroads and better long-distance communication became common in this time period. Businesses needed a more permanent way to keep track of time than sunrise and sunset because dawn and dusk can vary dramatically in different locations. This was important as business moved from local to taking place over longer distances.
Near the end of the 19th century, Greenwich Mean Time (GMT) and Universal Time (UT) were defined, subsequently allowing for the creation of today’s 24-hour time zone system. Most major countries did not adopt a mostly-standard hourly offset of GMT/UT until the time of the Great Depression (1929). Nepal became the last country to standardize on an hourly offset in the 1980’s.
While GMT has since become simply a time zone, UT is used as the standard for time tracking. It’s based on highly precise calculations using atomic clocks and the Earth’s rotation. Coordinated Universal Time (UTC) was developed in the 1960’s and finalized in 1972 (leap seconds were added) to standardize civil time.
Around the same time that time zones were being considered, Daylight Saving Time (DST) was also on the minds of newly industrialized minds. DST allows for societies that follow a stricter clock-based schedule than one that follows daylight hours. Countries that use DST adjust all clocks forward to allow for more access to sunlight in the evening hours during the summer.
Nowadays, time zones and Daylight Saving Time provide us with a regular, dependable system for keeping track of our lives every single day. But that's just for people like you and me. What about the machines?
When we look for the time today, it's often not on a regular watch or desk clock. It's more likely that you'll pull a phone out of your pocket, check a smart watch, or look in a corner of your computer’s display.
Computers are very good at telling time. They might be the best, in fact. You can give a computer the time in Ireland and it can instantly convert it to the time in Atlanta then display it in any format you desire.
Considering the importance time plays in almost every industry in the modern world—stock markets, for example, would collapse without proper timekeeping—computers have to do exactly what you desire with a provided time and return the result quickly.
Considering the complex nature of computers, we often take for granted the simplicity with which our devices tell us the time. If you're a software developer, there might be an opportunity to improve your workflow by paying more attention to time when you start working with a new bare metal or virtual server.
Computers and Time Zones
One of the first requirements for configuring a new computer is often verifying or setting the current time and time zone (EST for East Coast-living Americans). The average person will set the time on their personal computers to the local time. It wouldn't make sense to do anything else if you're the only user or the device won’t ever leave your home. Modern desktop operating systems can even display secondary and tertiary time zones if you're traveling often with a laptop.
Setting up a server is not much different. Software developers may bring personal habits to the workplace by standardizing all of their personal development servers to their local time plus time zone. Local time may not always the best time to develop in, though.
First, If you live in a country with Daylight Saving Time, your computers are (hopefully) changing time on their own twice a year. This is fine for your personal devices but a server with time-stamped log and/or backup files may run into issues twice a year during the switch.
Microsoft’s Internet Information Services (IIS) tool is one example. This Windows Server application has had issues in the past with writing log file timestamps due to a specific log filetype used. Solutions were available, fortunately. Windows NT was another Microsoft product with issues. It kept timestamps based on GMT which meant file timestamps looked different based on what time zone a user was located in. A third example comes from WebTrends, a web analytics platform. Their analytics tool had issues with log files at the start and end of Daylight Saving Time.
Second, a question. Does your work exist entirely within one time zone? It's more likely that your work has at minimum a national reach and more likely In today's world economy, a global reach.
Software development takes place all around the world by often disparate individuals often working as part of a remote team. If you're the lead developer in NYC on a team spread between New York City and San Francisco, you may decide to set up the first servers according to time on the East Coast. While it may seem fine initially, you could run into issues in the future.
What if another team in the West Coast office starts a server with local time set and it becomes a production server before you can intervene? If the remote servers are communicating with each other, there might be issues as you create important tasks and need to coordinate time between servers. The more servers that you have with disparate time zone offsets, the more likely you are to run into issues.
What happens when you open a branch in Asia and don't remind that team to choose either the Eastern or Pacific time zones when setting up servers? Now you'll have a third time zone to worry about and this one is dramatically different than the plus/minus three hours your team was dealing with before.
Keeping Time is Difficult but Essential
One simple solution to avoid headaches is to build protocols that must be adhered to for all DevOps activities. A simple guideline like requiring all servers to be set to a single time zone can be advantageous for the present and future. Add it your employee onboarding to facilitate easy knowledge-sharing.
Requiring all servers to have UTC set as the default time standard on every server is another alternative to prevent any guesswork on conversions. UTC is not affected by time zones so that’s a strong proponent for simplifying your work. If there is a hard requirement for local time, be sure to add the time zone offset from UTC to timestamps. This should ease any pains in future date and time conversions.
These are not definitive solutions, though. There are many other possible arguments surrounding time that could derail our possible solutions. Take into account the fact that many businesses operate in civil time and time zones or Daylight Saving Time may be adjusted in the future.
Per the Energy Policy Act of 2005, The U.S. adjusted DST in 2007 by moving the time change dates up a few weeks. It could happen again and cause havoc on your plans. There is a large group that is lobbying for Daylight Saving Time to be abolished so you might have to plan for that contingency as well.
Pair that with our list of other references below if you’re interested in learning more.