Time Zones Are Challenging

Without a doubt, time and time zones is one of the most “painful” and difficult topics for everyone who is involved in software development in one way or another. And we are not even talking about major international projects that may affect various countries and continents. It’s enough to understand that there are 10+ different time zones within the US alone, and if we add daylight savings time.

As tempting as it is, I won’t take the comedic approach to summing up what every developer must face with this issue. This has been done many times over and over (as an example, I will recommend the following video).

A QA Point of View on Time Zone Testing

The role of QA with the complex issue is definitely not do is advise which libraries to use, or how we will convert time or not. In my opinion, QA’s approach should be the same with any complex topic–maximum awareness on the topic and specific practical ways to avoid or solve it.

For example, with time zones, a tester should really understand what they are, how the transition to summer / winter time works (daylight saving time, in the US), basics like how many seconds are in a minute, and so on. Armed with this knowledge, the probability is closer to 100% that we will be able to offer and develop more competent check options. If, when reading the previous sentence, you had a question: “Who would not know how many seconds are in a minute?”, then this blog is perfect for you!

To get started, I would like to build a further analysis of the topic as follows. First, I’ll outline some basic terms and concepts of time and time zones. Next, I’ll cover the most commonly unknown facts or misconceptions about time zones. Finally, I’ll offer you my practical recommendations on how to best test on a software project with time zone considerations.

The Basics

At the heart of time zones is the concept of UTC. UTC stands for Coordinated Universal Time (with the words ordered the other way in French). Despite the common misconception, UTC is not itself a time zone. UTC, is the primary time standard by which the world regulates clocks and time. It is kind of a “ground zero” for all other time to be measured against.

Since time is different in different parts of the world, it is usually described as UTC plus or minus a certain offset. But, it’s important at this step not to confuse offset with time zone. For example: UTC-7:00, UTC+3:00, etc do not represent time zones. They instead represent the UTC offset — at a given moment of a particular region’s time. A time zone is defined as a geographic area with a specific offsets during different parts of the year.

Also many time zones observe daylight saving time, so a time zone’s offset can change depending on the time of the year. Daylight saving time (DST) is the practice of advancing clocks (typically by one hour) during warmer months so that darkness falls at a later hour, then putting it back for winter. The typical implementation of DST is to set clocks forward by one hour in either the late winter or spring and to set clocks back by one hour in the autumn to return to standard time.

Now when we have a basic understanding of main concepts about time and time zones we could discover the most interesting and surprising misconceptions about time. 

Common Misconceptions About Time Zones

Time Zone Offsets Are Not Always Full Hours

Time Zone Offsets Are Not Always Full Minutes

Time Zones Are Not Always Between -12 and +12

Midnight Is Not Possible On All Dates

DST Is Not Always +1 or -1 Full Hour

Not All Time Zones Observe DST

GMT and UTC Are Not The Same

Leap Years Don’t Always Happen Every 4 Years

Some Calendars Have Leap Months

A Year is Not Always 365 or 366 Days

Recommended Testing Process for Time Zones

The following matrix shows the most common test cases I use to try to test all of the unexpected things about time and time zones outlined above: 

Additional test cases could be useful if we have to test, for example, an ongoing event which takes place in the transition between DST. My last advice would be to test a couple of time zones that use half-hour offsets. This Matrix plus these additional test-cases will cover a solid percent of the test-cases related to time and time zones.

My only remaining recommendation is how actually change time on your computers for these tests. Previously, a common way to do it was to change your computer’s current time zone in the settings, but for testing web application, I now recommend simply use the Chrome developer instrument for that. It’s more accurate, convenient and reduces the possibility that the browser will circumvent your local change your time locally, and still figure out your actual time zone. 

3 dots menu in dev console —> more tools —> sensors 

From here, simply set up your location in a different time zone, and go straight to your testing.

Summary

Time zones are difficult, and there a lot of hidden details that can make testing time-zone-aware code tricky. Educating yourself on the intricacies of time zones can help you to test for all the edge cases better, and coming up with a list of those cases, as I have suggested, will help you ensure you’ve tested them all carefully every time.

Thanks for reading. I hope you found it helpful!