Time zone usage in the IntelliSurvey platform

As of Version 8.0, every timestamp shown in the admin application will use a more descriptive and useful date/time string. Moreover, it will be calculated to use a date/time consistent with the user's time zone. This can be changed in User Preferences.

This document outlines some of the considerations that must go into displaying and using time related data. It is not as easy to work with as one might imagine, but our developers have done the heavy lifting to provide a more seamless experience for the admin users. Enjoy!

Background

Pacific Time Zone - those of us at IntelliSurvey know it and use it. It is where our head office is located, where many of us work, and is pretty much the context of everything time-related in our daily routines.

We have all become used to thinking in Pacific Time with respect to doing data searches, report generation, etc. But now, in the global world, we must be able to adjust the mindset of our data - how we view it and mine it. And unfortunately, our current method of changing the "view" using UTC offsets isn’t as accurate (or easy to use) as we might think.

While we do store our data as UTC values, we currently query that based on (for the most part) a default context of our own company’s time zone - Pacific. You may ask for responses on June 5th between 1am and 1pm, and you get the right values for that inquiry. 

If we needed to do a search for 1am to 1pm in New York - we would run the report and select the offset of New York (-4). That worked, for the most part. But even then - twice a year - that specific report might generate inaccurate results, that being the two days when time zone offsets change at 2am during daylight saving changes.

So moving forward, we need to use a system which can provide a single context for a date range, but be dynamic in nature to adjust for variations in time zone changes throughout the year, regardless of location.

Welcome, time zones.

The time zone database

In 1986, an established list of world time zones and their rules was created to help with the complexity of coordinating and calculating time correctly. The database maintains a list of historical time zone information, including transitions between daylight savings and standard time and leap seconds.

This database is responsible for ensuring that each computer knows how to keep time according to its designated time zone and is incorporated into every computer’s operating system. It is why a computer in Los Angeles will switch to daylight saving time (DST) the 2nd Sunday of March every year, but a computer in Phoenix won’t, and how it knows exactly what time to display for any other place on Earth at any given second.

This database contains information for over 380 different time zones across the globe and includes all the rules for constructing a correct UTC time for each time zone name given any date/time. The rules track not only the GMT offset, but also daylight saving information and historical information about any changes to daylight savings observance (including the years that daylight saving time started in the US on January 6th, 1974, lasting 10 months, and then again in the US on February 23rd, 1975, lasting 8 months).

Starting with IntelliSurvey’s Version 8.0, you will now see that many of our reports and other date/time related input options have drop downs which permit you to select a time zone reference for your date-related task. This normally is defaulted to your own computer’s time zone unless you have manually changed your time zone in your user preferences (another option new to 8.0). 

This list is currently small, but may expand to include more time zone names.

Time zones vs. offsets

It has been said many times, many ways: Offsets are not time zones, and time zones are not offsets. For clarity, we define these terms as:

• Time zone: a geographic region or area that follows a set of rules for time changes and offsets from UTC on specific dates. This includes historical information about these rules and changes to them throughout history. 
  A time zone may have different offset values depending upon the time of year and the year itself.
• Offset: the number of hours or minutes a certain time zone is ahead of or behind GMT (which is UTC with an offset of 0). A time zone’s offset can change throughout the year because of daylight saving time. Sometimes laws change a time zone’s offset or daylight saving pattern.
  An offset, at any given moment in time, is shared by multiple time zones.

When we say, “Indiana switched from Central to Eastern Time,” we actually mean “Time zones in Indiana changed from one offset to another.”

Clarification of time zone abbreviations and time zone names

“What about things like ‘Eastern Standard Time’, ‘PDT’, ‘Central Daylight Saving Time’, etc.?” you may ask. Colloquial time zone names and their abbreviations (e.g., Central Daylight Time/CDT) are historical in nature and still used today to represent a locally recognized time zone abbreviation along with the state of daylight saving. These values change depending upon the date value. In other words, they are not static and do fluctuate.

Official time zone names (e.g. - America/Chicago), also known as Olson Time Zones, are used for establishing a concrete location in the world. These names are keys to the rules in the Time Zone database mentioned above. These rules are used to calculate a correct UTC value from any given date/time string without having to know anything about UTC offsets.

Why the switch?

As we shift to a more global client base, we need to be able to accommodate working in the context of clients’ time zones. SaaS customers will also need to be able to work in their own time zones without knowing where our servers are located. Times should (and will) always be displayed relative to the user’s time zone unless otherwise specified.

The use of an offset for time based queries or scheduling can be inaccurate, especially for recurring events (like report scheduling, as outlined in the next section). As well, specifying an offset to apply to a date range can produce incorrect results as offsets for a location can change for some, and not for others (Hello, Phoenix).

Using time zone names rather than static offsets ensures that database queries with date ranges will be calculated correctly no matter what values you enter (historical or in the future).

Dates & Times - The trouble with offsets

Time is a funny thing. Setting a report to generate at 10am every day would be a simple task, right? Not really.

Consider a server using the Pacific time zone. A 10am report generation is pretty easy to figure out: the report is generated when the server hits 10am. Of course, that is easy only if the report is asked to be generated daily at 10am Pacific.

But what happens when we need to send off a report at 10am Eastern every day? A bit of adjustment is needed, but nothing too complicated. Knowing that Eastern is 3 hours ahead of Pacific, we would just subtract 3 hours from 10am Eastern and send out the reports when the server hits 7am. 

And no need to worry about the twice yearly time change as both Eastern and Pacific regions change time at the same time, maintaining the same 3 hour time difference.

But what about a client who lives in Paris who also wants their reports to be generated at 10am? That is where things get a bit more complicated.

Take the case of these 3 customer reports, all scheduled to be run daily at 10am in their respective time zones. The top row shows example dates on which a report is to be generated. The remaining rows show the customers’ respective time zones, the state of standard or daylight saving time on that date, and the correct server time at which their report should be run to facilitate a report generation at 10am local time.

The actual run times for these reports change based on time of year. It requires both the desired local run time (10am) and the reference time zone to correctly calculate the next scheduled server runtime.

Summary

Moving to using time zone names will produce more accurate data mining, and correct context for reports, charts, and data exports. It will allow all IntelliSurvey clients and users to work in the context of their respective time zones, not ours. And most of all, we will be moving our system to a more dynamic, user-friendly, and standardized naming of time zones, rather than an old and outdated way of adjusting times.

For a breakdown and exploration of how complicated time zones really are, you may wish to view this humorous video courtesy of Tom Scott and forwarded to me by our own Alexander Lee.

Link: The Problem with Time & Timezones - Computerphile