Why is city timezone used instead of region timezone for tzinfo?

Question

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 time zone 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.

Answer 1

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

Names of time zone rule files

The time zone rule file naming conventions attempt to strike a balance among the following goals:

• Uniquely identify every national region where clocks have all agreed since 1970. This is essential for the intended use: static clocks keeping local civil time.

• 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 a consistent naming convention over the entire world. This simplifies both use and maintenance.

This naming convention is not intended for use by inexperienced users to select TZ values by themselves (though they can of course examine and reuse existing settings). Distributors should provide documentation and/or a simple selection interface that explains the names; see the 'tzselect' program supplied with this distribution for one example.

Names normally have the form AREA/LOCATION, where AREA is the name of a continent or ocean, and LOCATION is the name of a specific location within that region. North and South America share the same area, 'America'. Typical names are 'Africa/Cairo', 'America/New_York', and 'Pacific/Honolulu'.

Here are the general rules used for choosing location names, in decreasing order of importance:

• 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 all the clocks in a country's region have agreed since 1970, don't bother to include more than one location even if subregions' clocks disagreed before 1970. Otherwise these tables would become annoyingly large.
• 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.

The file zone.tab lists the geographical locations used to name time zone rule files. It is intended to be an exhaustive list of canonical names for geographic regions.

---

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