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 the technology handles time zones, and ways to avoid time zone issues in software development and infrastructure management.

(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 1980s. 

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 1960s 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?

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.

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 be the best time to develop, though. 

First, If you live in a country with Daylight Saving Time, your computers are (hopefully) changing the 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 file type 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 logfiles 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 a 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.

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 a future date and time conversions. 

These are not definitive solutions, though. There are many other possible arguments surrounding the 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.

W3.org - Timezones

Server Fault - "Should servers have their timezones set to GTM / UTC

Creative Deletion - Timezone updates need fixing

Creative Deletion - Persisting Future Datetimes

EECIS - NTP distribution

Wikipedia - Daylight Savings (Computing)

Wikipedia - Time Zone

Wikipedia - Civil Time

Time and Date - Time Zone History