Time zones and Flux — Part I
Time zones are an interesting topic because there are multiple ways to talk about them, even though most people don’t realize it. If you’re a developer, however, you better know the difference.
This is the first part of a two-parts series on time zones. You can find the next article in the series here.
Time zones as fixed offsets
We tend to work with two different definitions of a time zone, and that can make things confusing. One way is to define a time zone is to as a fixed offset from Coordinated Universal Time (UTC). These fixed offsets are typically in semi-hourly or hourly increments (e.g. UTC-08:00). In conversations, these offsets would be really awkward (e.g. “let’s have a conference call at 3PM UTC-08:00”, “say what?”), and so they’re often replaced by easier to digest text labels (e.g. Pacific Standard Time for “UTC-08:00”). These text labels in turn are shortened into time zone abbreviations. These abbreviations are sometimes ambiguous, and require the speaker to have enough context to disambiguate them. Try to coordinate a conference call in winter between a person in Israel (Israel Standard Time, IST, UTC+02) and one in India (Indian Standard Time, IST, UTC+05:30), and see how much mileage you get with these acronyms.
To complicate matters, each geographic location can pick whatever time zone (“the fixed offset for UTC”) it finds convenient. Heck, each location can even decide to spend part of its year in one “fixed offset from UTC”, and another part of the same year in a different “fixed offset from UTC”. And to do that only for some years and not for others. That’s in a nutshell the complexity added by Daylight Saving Time (DST), but it’s also the complexity added by legal and political changes over time.
Time zones as location-based, variable offsets
This leads us to a second definition of “time zone”. In this second definition, a “time zone” is the “local time” associated to a specific location, but based on arbitrary policies, rather than a geographic position. This definition of “time zone” describes a variable offset from UTC, not a fixed one. In this second definition, a location like San Francisco gets assigned to the time zone Pacific Time (PT), but that label includes two fixed offsets — Pacific Standard Time (PST) and Pacific Daylight Time (PDT) — which create a second layer of ambiguity that can only be resolved once you have a specific point in time to operate on.
To make a more amusing (maybe?) example, the town of Greenwich, famous for being the home of the Greenwich Mean Time (GMT) time zone, actually drops GMT for British Summer Time (BST) every summer to follow the rest of the UK during the DST period.
This second definition is complex, yet it can be used in programming languages, although not with the ambiguous labels described so far. This is where IANA comes in, with the IANA time zones database and its identifiers. A database is needed because each IANA time zone identifier must track the arbitrary history of “fixed offsets from UTC” for the reference location described by that identifier.
Take for example the label Mountain Time. A lay-person would say that Calgary (AB) and Phoenix (AZ) are both in the Mountain Time (MT) time zone. However, Calgary follows the rules of the Alberta province in Canada (including summer changes for DST), while Phoenix follows the rules of Arizona. Arizona for the most part doesn’t use DST, except that it did in 1918, 1942, 1943 (for the whole year) and 1944. And except that the Navajo Nation uses DST, and its territory spans Arizona, New Mexico and Utah.
All of this complexity is neatly encapsulated in three IANA time zone identifiers: America/Edmonton, America/Phoenix and America/Shiprock. Edmonton is the capital of Alberta, Phoenix is the capital of Arizona, but Shiprock is neither in Arizona, nor the capital of the Navajo Nation. This is just to say that given a location on a map, it’s probably hard to guess what’s the right IANA time zone identifier to use, so don’t let your developers try, just ask your end users.
Time zones and programming languages
Standard programming languages don’t work well with ambiguous inputs, and that’s why the fixed offset time zone abbreviations (PST, PDT, etc.) can only be used to generate human readable output, but not to process data describing points in time.
Timestamps can be exchanged as strings with fixed numeric offsets attached (but not ambiguous labels), like in the ISO 8601 format. When that is the case, each timestamp carries its own time zone information. While this eliminates ambiguity (and that’s a desirable property for data exchange protocols), it adds overhead.
Alternatively, timestamps are stored as numeric offsets from an arbitrary origin (e.g. the UNIX Epoch time). When that happens, the time zone information must be carried separately, and that’s when the IANA time zone identifiers come in handy. Each timestamp can be stored without its own time zone information, but the time zone data for the entire data set can be reconstructed unambiguously, from location-specific events stored in a small database.
Note also that if you only need to work with intervals between timestamps, you won’t need any time zone information.