A sensible compromise. I would support 1 and 2, and agree with postponing consideration of 3. David Braverman -----Original Message----- From: tz-bounces@iana.org [mailto:tz-bounces@iana.org] On Behalf Of Robert Elz Sent: Wednesday 22 May 2013 09:14 To: tz@iana.org Subject: Re: [tz] Dropping iso3166.tab Personally I'd like to drop countries - not just from zone.tab but from everywhere, and so avoid all kinds of problems. But I don't see that happening any time in my lifetime, unfortunately. Certainly we should be rid of the political decisions from this project. We don't need t be making them in fact, as much as possible, we shouldn't be making any decisions at all, that is not what this project is about. What we do is collect and publish data. That's it. Unfortunately, to do that we have to make some decisions - including stuff like the name of the file the data is published in (mostly relatively uncontroversial, fortunately...) and the names of the data items that are published (more controversial, though we could reduce controvery by switching to using completely meaningless labels.) However, we cannot delegate decisions to the UN, or ISO, or (possibly aside from people who participoate in this project) to anyone else - none of them work for us, we do not get to tell them what to do, or to demand that they make some kind of decision that we need made. For example (and I know this one is extremely far fetched) suppose that the people who live in the region of Kosovo, which might or might not be recognised as a country, sooner or later, were to decide, today, that as from Sun June 2 2013, they were going to change their timezone, and that was reported to us, later today. We would have a week and a half to make and distribute a new tzdata distribution with the new zone in it. Tight, but we've done that before. But, if we're depending upon ISO, or the UN, or someone to decide what country code to apply, what do we do next? Frantic phone calls to the UN secretary general demanding a decision or we'll sack him? Not going to work, is it? Still, we have to publish the data, or we've failed. We need to make the decision for any decisions that need to be made. So, obviously, reducing the number of those decisions that are needed helps, and where possible, making those decisions be ones where there is as little scope for argument as possible. Then we can go back to just collecting and publishing data, So, I have a counter proposal to that made by Paul Eggert - with similar objectives, just achieved in a slightly different way. Paul suggested 3 operations. The first, removing iso3166.tab is a no-brainer we can easily do that - anyone who wants a copy can get it from other sources. For zone.tab (assuming that the other solution, of simply moving it, and tzselect, to some other project isn't adopted) rather than making column 1 be a comment, define it to be a region, expressly not a country, and explicitly not using (however similar they may seem) ISO3166 2 letter identifiers. Instead define it as simply being a tz project specific identifier used to group related zones that apply within some tzdata defined region together. Of course, in practice, most of the time we'll keep using identifiers, that, by pure accident of course, happen to be the same as the 3166 2 letter identifier for the country that has rather similar boundaries to our region, without ever, of course, implying they are the same, and without ever claimimng that some city belongs to a particular country - that is none of our business, nor do we care one way or the other. Step 3 of Paul's plan I'd avoid for now - that is, merging zones that could be merged. Not because it is the wrong thing to do, but because it is a whole bunch of work for no immediate gain. All the old zones would still exist (or seem to exist) in the output from zic (the stuff that people actually see) because of the "backward" entries we would need to create. Instead, I'd simply allow zones to be merged if at some future time doing so will make life easier - so if in the future, something changes that would need updates to a whole bunch of identical zones, it might at that time be easier to merge them into one (and add backward links) simply because that's easier to do than the same edit several times. kre