On Tue, 10 Jul 2007, Claus Färber wrote:

If city is defined as municipality, the following are wrong:

Europe/London should be Europe/Birmingham

Not if it's London as in the Greater London Authority (or, historically, the Greater London Council, the London County Council, etc.), as opposed to the City of London which has been only a small part of the geography and government of the greater city for centuries. Tony. -- f.a.n.finch <dot@dotat.at> http://dotat.at/ IRISH SEA: NORTHWEST 4 OR 5, OCCASIONALLY 6. SLIGHT OR MODERATE. SHOWERS. MAINLY GOOD.

Claus Färber said:

...

Not if it's London as in the Greater London Authority (or, historically, the Greater London Council, the London County Council, etc.), as opposed to the City of London which has been only a small part of the geography and government of the greater city for centuries. The GLA is a super-city authority, covering multiple cities such as the City of London, the City of Westminster, etc. Well, that just proves my point that the term "city" introduces ambiguity.

The term "city" has at least three meanings within the UK: (1) [the legal definition] A local authority area granted city status by the crown. The LA may be a District, a Borough, or a Parish. (2) [the pub lawyer's definition] A conurbation containing a cathedral. (3) [colloquial] A large conurbation. London is a city under the second and third definitions, and a local authority area containing two cities under the first. But so what? Every country has its own concept of what a "city" is and how it differs from a town. The colloquial one is probably better *FOR THIS PURPOSE* than either of the other two.

It's simply inconsistent to treat Greater London as a "city", which is made up of multiple municipalities like the City of London, Westminster, etc.,

They aren't municipalities, they're boroughs. And Birmingham is equally split up into wards. So what?

It's also inconsistent to treat Greater London as a "city" and not Greater Milan (7 million), which would be substantially larger than Rome or Greater Rome (2.5 or 3.3 million).

Does "Greater Milan" have a single governmental authority? -- Clive D.W. Feather | Work: <clive@demon.net> | Tel: +44 20 8495 6138 Internet Expert | Home: <clive@davros.org> | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 THUS plc | |

As the term city is ambiguous, the standard is ambiguous and inconsistent anyway.

How can we put an end to the incessant disputation over time zone identifiers? If we go by metropolitan area populations, someone will say we should go by central city populations. If we use any criterion that chooses Hanoi, someone will say Ho Chi Minh City is more important; but others will argue that the capital city is always more important. We must bear in mind that these are only supposed to be identifiers. Conceptually, we could be using WT/QAF just as well as Europe/Rome. It was merely for the convenience of developers that mnemonic names were chosen. But it is the responsibility of a user interface, not of the tz database, to translate the time zone identifiers into user-friendly names. The volunteer maintainers of the tz database have plenty of work to do, just to keep it up to date. If their job description is expanded to include making sure that the definitions of cities are consistent, providing universally acceptable names and abbreviations for time zones, or enabling localization by giving the translations of city, country, and time zone names into an arbitrary number of languages, I believe that puts too much on their plate. Presumably the CLDR addresses localization issues. Whoever maintains the CLDR has undertaken responsibility for interpreting the identifiers into human-readable form. Identifiers should be stable, too. True, by using backward-compatibility links, we can minimize the disruption caused by changing an identifier. Still, any kind of change has its cost, and a lot of the cost is hidden. We don't know how many people have used "Europe/Rome" somewhere in their code or nomenclature or documentation, and would deem it necessary to change the string if the primary name of that time zone changed to "Europe/Milan". (Of course, some changes are unavoidable, when time zones split.) My suggestion would be to state boldly in the documentation, "Time zone identifiers are arbitrary. Although they look as if they have a geographic interpretation, there is no guarantee that they do, or will continue to in the future. They should not be displayed directly to end users." Then, if possible, there should be some discussion of how to display time zone information to users. If we get GIS files for time zone boundaries, that will be a big help. Maintaining the boundary files would fall within the purview of the tz mailing list. Gwillim Law

I agree with Gwillim Law; these are just identifiers. As far as I'm concerned, the best strategy would be 1. Never change remove or change what is in zone.tab. 2. Only add a new identifier to zone.tab if a zone splits. 3. For such a new identifier, pick the largest city in the new zone according to some reasonable authority (eg National Geographic Atlas of the World). Since it is just an identifier, don't worry about whether or not it includes metropolitan areas or how; don't worry about whether the authority is the best possible one or not. 4. Make sure that last field is unique, eg don't have America/United_States/San_Jose if you have America/Costa_Rica/San_Jose. If it would not be unique, choose a different identifier for zone.tab, or have some minor modification (San_Jose2) 5. Add aliases (links) where useful for clarification. Short of that, the current policies are reasonable, although it forces other parties (like CLDR) to impose additional measures for stability of identifiers. Mark On 7/10/07, Paul Schauble <Paul.Schauble@ticketmaster.com> wrote:

I suggested some time ago that zones should be named according to the authority that declared the zone. This would often result in country names or country name (subdivision). But it would also clearly identify things like "Navajo Time" as such rather than lumping this in with "Denver".

I think this gives a more stable system that largest city. It completely avoids the issues of what is a city. And it avoids changing zone names when city population changes.

++PLS

-----Original Message----- From: rlaw@nc.rr.com [mailto:rlaw@nc.rr.com] Sent: Tuesday, July 10, 2007 11:38 AM To: tz@lecserver.nci.nih.gov Subject: Re: Vietnam: Saigon is deprecated, should use capital Hanoi

...

As the term city is ambiguous, the standard is ambiguous and inconsistent anyway.

How can we put an end to the incessant disputation over time zone identifiers? If we go by metropolitan area populations, someone will say we should go by central city populations. If we use any criterion that chooses Hanoi, someone will say Ho Chi Minh City is more important; but others will argue that the capital city is always more important.

We must bear in mind that these are only supposed to be identifiers. Conceptually, we could be using WT/QAF just as well as Europe/Rome. It was merely for the convenience of developers that mnemonic names were chosen. But it is the responsibility of a user interface, not of the tz database, to translate the time zone identifiers into user-friendly names.

The volunteer maintainers of the tz database have plenty of work to do, just to keep it up to date. If their job description is expanded to include making sure that the definitions of cities are consistent, providing universally acceptable names and abbreviations for time zones, or enabling localization by giving the translations of city, country, and time zone names into an arbitrary number of languages, I believe that puts too much on their plate.

Presumably the CLDR addresses localization issues. Whoever maintains the CLDR has undertaken responsibility for interpreting the identifiers into human-readable form.

Identifiers should be stable, too. True, by using backward-compatibility links, we can minimize the disruption caused by changing an identifier. Still, any kind of change has its cost, and a lot of the cost is hidden. We don't know how many people have used "Europe/Rome" somewhere in their code or nomenclature or documentation, and would deem it necessary to change the string if the primary name of that time zone changed to "Europe/Milan". (Of course, some changes are unavoidable, when time zones split.)

My suggestion would be to state boldly in the documentation, "Time zone identifiers are arbitrary. Although they look as if they have a geographic interpretation, there is no guarantee that they do, or will continue to in the future. They should not be displayed directly to end users." Then, if possible, there should be some discussion of how to display time zone information to users. If we get GIS files for time zone boundaries, that will be a big help. Maintaining the boundary files would fall within the purview of the tz mailing list.

Gwillim Law

-- Mark

Date: Tue, 10 Jul 2007 15:12:44 -0700 From: "Paul Schauble" <Paul.Schauble@ticketmaster.com> Message-ID: <0165EECEBB4CF745ACF095E1176B03EA12C7FFE3@SUNCA-EXB-AV1.ticketmaster.corp> | I suggested some time ago that zones should be named according to the | authority that declared the zone. Does that work in the US, where all zones are under the authority of the Dept of Transport (or something like that) - you'd still need additional names to determine just which of the multiple different zones they meant - and even then dealing with historical names would mean that you can't just use the names the relevant dept assign, as they don't usually bother to provide names for things which are no longer current, but we need them. Just stop arguing about this silly issue - it doesn't really matter what the zones are called. City names are a fairly good choice, as it is very unlikely that a single city doesn't have a single timezone history and rules. Further, the biggest city is a good choice, as it is unlikely that people aren't going to know if the local time is different than whatever is the biggest regional city. Definitions of cities don't need to be precise - nothing really important depends upon the results - we aren't specifying the time that applies in that city, just using its name as the label for a time zone (where any unique label would do just as well - which is why when the city that would normally be selected doesn't have a unique enough name, we just pick another.) A "city" is just what some outsider would consider to be that city, so as far as I'm concerned, if I arrive at Heathrowe (or Gatwick) I'm in London. On the other hand, if I'm in Essen, I'm in Essen, the city, Ruhrgebiet, or Rhein-Ruhr is a region name, not a city, so they're not really options for us to choose. Stability is not too much of an issue either, nothing depends upon "biggest" that's just a convenient way to (try to) pick cities without having these endless absurd arguments. That's why "most important" is never going to work - all that would ever do is cause arguments, never settle any. Once picked, we retain the same city name, even if something else becomes bigger - at least until it is clear that some other city is substantially larger and going to remain that way. Whether we should be using Rome or Milan in Italy, I'll leave to someone who understands Italian geography and politics - if it should be Milan, we can just fix it (and of course, keep Rome as an alias). That is, if everyone who knows enough to have an opinion on this (which certainly excludes me) agrees that Milan is substantially bigger than Rome, and that isn't likely to change. If the issue is debatable enough for anyone to argue (reasonably) about, then we should just stick with what we have. The same for Calcutta/Mumbai and Karachi/Lahor. We already had the Beijing/Shanghai discussion, and while it may alter in the future, things don't yet seem clear cut enough to make a change there. kre