A time zone is a region on Earth that has a uniform, legally mandated standard time. As legal definitions of zones can vary wildly and change often, a database or lookup table is often required to properly apply time zone rules.

General Information About Time Zones

Almost all time zones on land have legally defined borders which coincide with the borders of the country mandating the time or some subdivision thereof. Of the time zones on land, most have a standard-time offset from Coordinated Universal Time (UTC) by a whole number of hours (UTC−12 to UTC+14), but several are offset by 30 or 45 minutes from a nearby hourly offset.

In addition to land time zones, there are 25 nautical time zones, all separated by lines of longitude. Most (UTC−11 to UTC+11) are 15° of longitude wide, which is one hour of Earth's rotation relative to the Sun, but an hourly zone in the central Pacific Ocean is split into two 7.5° wide zones (UTC±12) by the 180th meridian, part of which coincides with the International Date Line. Many land time zones are skewed toward the west relative to the corresponding nautical time zones.

Before 1972, all time zones were specified as an offset from Greenwich Mean Time (GMT), which was the mean solar time at the meridian passing through the Royal Observatory in Greenwich, London, United Kingdom. Since 1972, all official time services have broadcast radio time signals synchronized to UTC, a form of atomic time that includes leap seconds to keep it within 0.9 seconds of this former GMT, now called UT1. Many countries now legally define their standard time relative to UTC, although some still legally refer to GMT, including the United Kingdom itself. UTC, also called Zulu time, is used everywhere on Earth by astronomers and others who need to state the time of an event unambiguously.

Originally, all time on Earth was some local apparent solar time, the time on a sundial, so every city had its own time. When well-regulated mechanical clocks became widespread in the early 19th century, each city began to use some local mean solar time. The first time zone was created in 1847 by railroads on the island of Great Britain using GMT. Sandford Fleming of Canada proposed worldwide hourly time zones in 1879. By about 1900, almost all time on Earth was in the form of standard time zones, only some of which used a hourly offset from GMT. Many applied the time at a local astronomical observatory to an entire country, without any reference to GMT. It took many decades before all time on Earth was in the form of time zones referred to some "standard offset" from GMT/UTC. Nepal was the last country to adopt a standard offset, shifting slightly to UTC+5:45 in 1986. However, many countries have changed their standard offset since then, such as when North Korea shifted from UTC+9 to UTC+8:30 in 2015.

A related concept is Daylight saving time or Summer Time, which is an advance of (usually) one hour, mandated by many countries between spring and autumn.

Time Zone != Offset

A time zone can not be represented solely by an offset from UTC. Many time zones have more than one offset due to daylight saving time (aka "summer time") rules. The dates that offsets change are also part of the rules for the time zone, as are any historical offset changes. Many software programs, libraries, and web services disregard this important detail, and erroneously call the standard or current offset the "zone". This can lead to confusion, and misuse of the data. Please use the correct terminology whenever possible.

• An offset is just a number that represents how far a particular date/time value is ahead or behind UTC.
  • Most offsets are expressed in whole hours.
  • But there are many that are 30-minute offset.
  • And there are a few that are 45-minute offset.
• A time zone contains much more:
  • A name or ID that can be used to identify the zone.
  • One or more offsets from UTC
  • The specific dates and times that the zone transitions between offsets.
  • Sometimes, a separate language-specific display name that can be presented to a user.

One can determine the correct offset, given a time zone and a datetime. But one cannot determine the correct time zone given just an offset.

Time Zone Abbreviations

Many times you will see a time zone abbreviated using three or more letters, such as PST to abbreviate "Pacific Standard Time". However, there are many problems with time zone abbreviations:

• They are often ambiguous. For example, there are five different interpretations of CST:

  • Central Standard Time (North America)
  • Central Standard Time (Australia)
  • Central Summer Time (Australia)
  • China Standard Time
  • Cuba Standard Time

  See also, the list of Time Zone Abbreviations on Wikipedia.

• At best, they only represent a time zone offset, not a time zone. For example, the US Pacific Time Zone is abbreviated PST during Pacific Standard Time, but uses PDT during Pacific Daylight Time.

• Abbreviations tend to be based on English. Sometimes there is a valid abbreviation in another language, and it may be confusing which to use.

• Some time zones may never actually use the abbreviation in the region where the time zone is observed.

In general, if an abbreviation is used, it should be for display purposes. An abbreviation should never be parsed, or looked up in a list of values (with the exception of "UTC" or "GMT").

Time Zone Databases

There are two different time zone databases commonly used in computing:

The Microsoft Windows Time Zone Database

• Example Identifier: "Eastern Standard Time"

You can obtain a list of these time zones by any of these methods:

• Examine the Windows registry key at:
  HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones

• Use the tzutil.exe /l command line utility, looking at the second line of each result.
  (The first line is the display name.)

• Call TimeZoneInfo.GetSystemTimeZones from .NET, looking at the Id property of the resulting TimeZoneInfo objects.

• Call the EnumDynamicTimeZoneInformation Win32 function, looking at the TimeZoneKeyName field of the resulting DYNAMIC_TIME_ZONE_INFORMATION objects.

• DO NOT USE STATIC LISTS FROM WEB PAGES THAT LIST THESE WINDOWS TIME ZONES, INCLUDING THOSE FROM MICROSOFT. These should be ignored and not linked to or used as reference material. This is because time zones change over time and the lists have been modified significantly. In particular, several lists produced by Microsoft listing "time zone index values" only refer to time zones as they were for Windows Embedded 1.1, which has long been deprecated. Another list by Microsoft lists only the default time zone values per country when installing Windows for the first time. Third party lists are also suspect. Instead, use one of the aforementioned methods to list time zones on an up-to-date Windows system.*

Advantages

• Built in to Windows operating system.
• Updates are deployed automatically through Windows Update.
• Easy to consume from Win32 or .NET Framework on Windows.
• As of the June 2016 update, covers everywhere on Earth, except for a few research stations in Antarctica.

Disadvantages

• Maintained by Microsoft instead of a standards body or community.

• Zones tend to be broad, covering multiple countries and locations, instead of refined to a specific narrow location.

• Data for past years does not generally reach back very far into history, and is inconsistent with regard to starting year for the data that it does have for each time zone.

• Interoperability with non-Microsoft platforms can be painful.

• Updated monthly at best - which may or may not be frequent enough to deal with a short-notice change.

  • Previously, many changes were released only as hotfixes, but this has been changed in recent years such that all changes are deployed as regular updates.

• Identifiers and names are confusing and assigned haphazardly. Naming conventions have varied over the years, and there is little consistency. In general, do not rely on a Windows time zone identifier to mean anything in particular. Instead, choose a time zone based on its display name.

  A few examples:

  • "Eastern Standard Time" refers to both EST and EDT.
  • "Mountain Standard Time" is for MST/MDT while "US Mountain Standard Time" is for Arizona which is fixed to MST.
  • "US Eastern Standard Time" does have daylight saving time, from 2006 forward (but not for 2005 or earlier). It's used in the majority of Indiana.
  • "Romance Standard Time" is just a synonym for Central European Time.
  • "GMT Standard Time" refers to the time in the UK and Ireland that alternates between GMT (UTC+0) and BST or IST (UTC+1), rather than strictly referring to GMT itself. (For GMT year-round, use the identifier "UTC" instead.)
  • "W. Europe Standard Time" is the id for several countries that belong to the Central European Time zone, not the Western European Time zone.
  • "AUS Eastern Standard Time" and "E. Australia Standard Time" only differ by DST.
  • "Arab Standard Time", "Arabian Standard Time", and "Arabic Standard Time" are three completely different time zones with similar names.
  • "SA Pacific Standard Time" and "Pacific SA Standard Time" are also completely different.
  • "Russia Time Zone 3", "Russia Time Zone 10" and "Russia Time Zone 11" are valid identifiers, but other Russia time zones have names instead of numbers.
  • "UTC", "UTC-02", "UTC-08", "UTC-09", "UTC-11", and "UTC+12" are valid identifiers, but other offsets are not.

• As mentioned above, Windows time zones also have a display name.
  For example, "(UTC-05:00) Eastern Time (US & Canada)".

  • These names contain a time zone offset, but those offsets represent the standard time offset, not the current offset. This can be confusing, as the offset listed may not be the actual one in effect.
  • The display names are localized by the language settings of the Windows operating system. When used via TimeZoneInfo in .NET, the localizations are not updated to reflect the current culture or current UI culture. For example, you might have an application that serves data to an English speaking user, but when hosted on a Japanese server, the time zone display names will be presented in Japanese.

The IANA/Olson Time Zone Database

Also known as ZoneInfo, TZDB or the TZ database

• Example Identifier: "America/New_York"

Advantages

• Widely implemented on Linux, Mac, Java, PHP, and many other platforms.
• Libraries are available for JavaScript and for Windows/.Net.
• Refined, distinct time zones named from an exemplar city.
• Covers everywhere on Earth.
• Contains historical data for time zone changes.
• Referenced in many RFCs and other standards.
• Community maintained, recently backed by IANA.
• Frequent updates, several times a year.
• Some implementations make it easy to get updates:
  • On Linux with a package manager and the "tzdata" package.
  • On Mac OSX with Apple Software Update.
  • For Java, with JRE/JDK updates, or with the TZUpdater Tool.

Disadvantages

• Most implementations require manual updating, such as Noda Time, Joda Time, PHP, and others. (However, the ability to update manually could actually be considered an advantage.)
• There are so many zones, it can be difficult to present a simple drop-down list to your users. However, a map-based time zone picker, such as this one, can provide a good user experience.

Read more on Wikipedia.

Map of IANA/Olson Time Zones

This map shows the world map of IANA/Olson time zones, along with fixed offset time zones over the oceans. Note that many countries have multiple time zones.

^{Credit: Evan Siroky - Time Zone Boundary Builder project}

More time zone maps are available at Time_zone in Wikipedia.

Role of the CLDR

The Unicode Common Locale Data Repository maintains localized translations of IANA/Olson time zone names, as well as mapping between Microsoft Windows identifiers and IANA/Olson identifiers.

The mapping data is available in the second table on this page, or in xml format here. Note that there is usually more than one possible IANA/Olson zone for any given Windows zone. So one can translate an Olson zone to a single Windows zone, but the other direction will yield more than one possible choice. Also note that while every Windows zone is mapped, not every IANA/Olson zone is. So it is always possible to go from a Windows zone to (one or more) IANA/Olson zones - but not necessarily the other way around.

Related: How to convert between Microsoft time zones and IANA time zones in .NET.

POSIX style time zones

Prior to acceptance of the time zone databases, the standard way to describe time zones was defined by the POSIX specification, as set in the TZ environment variable.

Examples:

• PST8PDT
• CET-1CEST,M3.5.0/2,M10.5.0/3
• GRNLNDST3GRNLNDDT,M10.3.0/00:00:00,M2.4.0/00:00:00

While this compact format allows for time zone rules to be expressed without a database, it has a few disadvantages:

• Cannot express more than two transitions in a year, so it can't handle real-world events like Egypt in 2010 or Morocco in 2012, 2013, and 2014.
• Contains only the current time zone rules, so it cannot be used to accurately convert historical changes, such as USA before 2007.
• Are sometimes cryptic and difficult to read.

Fortunately, most environments that accepted a TZ variable, will now allow you to pass an IANA/Olson identifier instead. For example, see the third option for working with time zones in glibc.

IBM has a good article about POSIX vs Olson time zone formats here. (This was written for AIX, but is applicable in many other contexts.)

Rails Time Zone Identifiers

If you are a Ruby on Rails developer, or if you use an API from an application that was created using Rails (such as Twitter), then you may encounter time zone identifiers in a slightly different format, such as follows:

• "Eastern Time (US & Canada)" (instead of "America/New_York")
• "London" (instead of "Europe/London")

These identifiers are defined by Rails in the ActiveSupport::TimeZone class. The source code for this class is here. They are based on standard IANA/Olson time zones. Rails describes them as "a meaningful subset of 146 zones", however it does not describe by what criteria it determines a zone to be "meaningful".

While these particular zones should work just fine within a Rails application, you may find it difficult to use them in other contexts. For example, if you need to pass a time zone to a JavaScript library, or via a REST API to some third party, it may be difficult to consume them in Rails format. Rails developers should consider one of the two approaches:

• When exposing a Rails time zone identifier externally, use the ActiveSupport::TimeZone::MAPPING constant, which defines a dictionary back to standard IANA/Olson zone identifers.
• Use the Ruby TZinfo Gem instead of ActiveSupport::TimeZone. It provides access to the full IANA/Olson time zone database, and uses standard identifiers.

Related: How to convert from Microsoft time zones to Rails time zones.