[tz] [PATCH 4/4] yellow flags
tz at derickrethans.nl
Wed Aug 14 15:51:39 UTC 2013
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
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 );
For this it uses the zone.tab data file. With your proposed change, that
will now show:
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
> > 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
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.
More information about the tz