Take the 2-minute tour ×

This question is in regards to the standard list of timezones in the tzinfo aka Olson Timezone Database.

example 1: I have noticed that America/New_York or America/Detroit (known as "exemplar cities", see http://www.w3.org/International/docs/timezones/#tzids) are used instead of US/Eastern.

example 2: In Canada the Mountain timezone is usually described as America/Edmonton instead of Canada/Mountain. There are parts of British Columbia that are on Mountain Time, yet their timezone is specified as America/Edmonton (which is in Alberta).

In these cases, why would the region/exemplar city option be used instead of the country/zone version? There must have been a reason that the country/zone version was created in the first place, but why is it there if it isn't the preferred way?

This is mostly an issue when a country has more than one timezone.

Is there a best practices somewhere that says why one is preferred over the other?

(P.S. this is a difficult issue to Google for, as you get all un-related or unhelpful results. The closest thing I could find was Daylight saving time and Timezone best practices but it did not have this issue addressed.)

EDIT: can 2 timezone be for 1 city? there is "Since not everyone uses the canonical Continent/City notation for their time zone (I tend to use the older US/Pacific notation, for instance - which is still supported, but is equivalent to America/Los_Angeles)." His assertion that "US/Pacific" is older contradicts my indirect assumption that it was newer, but still not the answer.

share|improve this question
add comment

1 Answer

up vote 2 down vote accepted

The Theory file distributed with the Olson database contains the information:

Names of time zone rule files



  • Indicate to humans as to where that region is. This simplifes [sic] use.

  • Be robust in the presence of political changes. This reduces the number of updates and backward-compatibility hacks. For example, names of countries are ordinarily not used, to avoid incompatibilities when countries change their name (e.g. Zaire⟶Congo) or when locations change countries (e.g. Hong Kong from UK colony to China).

  • Be portable to a wide variety of implementations. This promotes use of the technology.





  • Use only valid POSIX file name components (i.e., the parts of names other than '/'). Within a file name component, use only ASCII letters, '.', '-' and '_'. Do not use digits, as that might create an ambiguity with POSIX TZ strings. A file name component must not exceed 14 characters or start with '-'. E.g., prefer 'Brunei' to 'Bandar_Seri_Begawan'.
  • Include at least one location per time zone rule set per country. One such location is enough. Use ISO 3166 (see the file iso3166.tab) to help decide whether something is a country. However, uninhabited ISO 3166 regions like Bouvet Island do not need locations, since local time is not defined there.
  • If a name is ambiguous, use a less ambiguous alternative; e.g. many cities are named San Jose and Georgetown, so prefer 'Costa_Rica' to 'San_Jose' and 'Guyana' to `Georgetown'.
  • Keep locations compact. Use cities or small islands, not countries or regions, so that any future time zone changes do not split locations into different time zones. E.g. prefer 'Paris' to 'France', since France has had multiple time zones.
  • Use mainstream English spelling, e.g. prefer 'Rome' to 'Roma', and prefer 'Athens' to the true name (which uses Greek letters). The POSIX file name restrictions encourage this rule.
  • Use the most populous among locations in a country's time zone, e.g. prefer 'Shanghai' to 'Beijing'. Among locations with similar populations, pick the best-known location, e.g. prefer 'Rome' to 'Milan'.
  • Use the singular form, e.g. prefer 'Canary' to 'Canaries'.
  • Omit common suffixes like '_Islands' and '_City', unless that would lead to ambiguity. E.g. prefer 'Cayman' to 'Cayman_Islands' and 'Guatemala' to 'Guatemala_City', but prefer 'Mexico_City' to 'Mexico' because the country of Mexico has several time zones.
  • Use '_' to represent a space.
  • Omit '.' from abbreviations in names, e.g. prefer 'St_Helena' to 'St._Helena'.
  • Do not change established names if they only marginally violate the above rules. For example, don't change the existing name 'Rome' to 'Milan' merely because Milan's population has grown to be somewhat greater than Rome's.
  • If a name is changed, put its old spelling in the backward file.


Note that there has been recent controversy (August 2012) on the tz@iana.org mailing list about the 'Shanghai in preference to Beijing' guideline.

share|improve this answer
This is great, but it'd be nice to know why is city used? Is that because a city may currently be the same timezone as a region but may not always be or have been? –  Juan Mendes Aug 17 '12 at 19:53
It's because region names change even more than country names. –  Jonathan Leffler Aug 17 '12 at 19:59
Some Cities, Counties and States politically choose to not follow the rules. Indiana is an example of this. –  FrankComputerAtYmailDotCom Aug 20 '12 at 3:09
Great information, Jonathan. It unfortunately doesn't say anything about these "US/Eastern" etc. and how they even came into existence. They make a lot of sense in my mind (moreso than the "America/New_York" variety) in countries of multiple timezones, but they do seem to violate the guidelines you have reproduced here so one wonders how they came to be. –  Pixel Aug 20 '12 at 15:29
@Pixel: The US/Eastern style names were an older variation of the naming convention, used before the one described above was put in place. That change was made quite a long time ago now (1990s, if not 1980s). The US/Eastern etc names still exist in the backward file referred to in the notes above; it is a link to America/New_York. –  Jonathan Leffler Aug 20 '12 at 15:56
add comment

Your Answer


