On Tue, 13 Aug 2013, Paul Eggert wrote:
Derick Rethans wrote:
Maybe that was the original idea, but that does not mean that people don't use it differently from the original intented usage.
Which usages are these, in practice? Nobody has mentioned any significant problems yet.
I can think of three already, without doing any further research into this. 1. Debian's "dpkg-reconfigure tzdata". Their ssystem allows you to select by region the top-level of the zone names: ┌──────────┤ Configuring tzdata ├───────────┐ │ Please select the geographic area in │ │ which you live. Subsequent configuration │ │ questions will narrow this down by │ │ presenting a list of cities, │ │ representing the time zones in which │ │ they are located. │ │ │ │ Geographic area: │ │ │ │ Africa │ │ America │ │ Antarctica │ │ Australia │ │ Arctic Ocean │ │ Asia │ │ Atlantic Ocean │ │ Europe │ │ Indian Ocean │ │ Pacific Ocean │ │ System V timezones │ │ US │ │ None of the above │ And then further restrict this by city-name: │ Time zone: │ │ │ │ Karachi ↑ │ │ Kashgar ▒ │ │ Katmandu ▒ │ │ Khandyga ▒ │ It does some strange things with the names from the "backward" directory, as you can see, the outdated "Katmandu" is in the list where as Kathmandu, the new name is not. They have a few exception/inclusions hard coded in their source packages and this is likely to break. 2. Debian's/Raspian's "tzselect" lists for "Asia": Please select a country. 1) Afghanistan 18) Israel 35) Palestine ... 9) China 26) Laos 43) Taiwan For this they use both zone.tab and iso3166.tab. They probably should change "country" to "region" there though... 3. PHP's DateTime support allows you to specify to list only a certain amount of timezone identifiers: $ids = DateTimeZone::listIdentifiers( DateTimeZone::EUROPE ); Or per country: $ids = DateTimeZone::listIdentifiers( DateTimeZone::PER_COUNTRY, "HR" ); var_dump( $ids ); Output: array(1) { [0] => string(13) "Europe/Zagreb" } For this it uses the zone.tab data file. With your proposed change, that will now show: array(1) { [0] => string(15) "Europe/Belgrade" } And I can assure you people will get upset by this. And all for no reason, as without the proposed changed *all works as it did*. I don't see why you are picking a political fight here, as there was no problem before.
I don't understand why the changes to zone.tab have to be made.
The problem is politics. We are trying to get the tz project out of the political issues of what the boundary between Country X and Country Y is, or whether Country X is actually a country.
Actually, I think you're making it worse by putting whole cities into different countries. You also need to realise that the ISO 3166-1 alpha-2 codes are *not* just for countries anyway. Wikipedia states: "represent countries, dependent territories, and special areas of geographical interest." — avoiding very nice the Taiwan/China and Israel/Palestine issue. Hence, I don't even see why we can't continue using those codes in the first place, as they're not reserved for countries in the first place.
When I created zone.tab originally, I was naive about how bad this could be, and I'm trying to change things slightly to avoid as many future political problems as I can without breaking things significantly. There is no perfect solution here -- no matter what we do, even if it's doing nothing right now, there will be more work to do later; but the political hassles are real, and will consume more and more of our resources as time goes on, and I'm trying to head as many of them off at the pass now as feasible.
Right, I agree there is no good solution, but there is a zone.tab file, and people are using it. And because there is no good solution, keeping the status quo, and thus keeping the database *stable*, is the only way to not make a new stance on anything. cheers, Derick