[tz] Dropping iso3166.tab

[Tim Thornton]

My thoughts are as follows, for what it's worth:
- Time zones apply to an area, not just the (near) point of a city, so at some stage. This may be done in software, e.g. the country code of the tz database mapping to a GIS boundary, or by the user associating London with UK. Whilst defining the geography of the boundary is outside of the tasks of the tz list, I think it is necessary to be able to have some sort of association from point to area
- There has been some talk about geolocation or getting data from a server. I don't think we can assume this is available, and tz data should stand alone without this
- There will always be debate about decisions made. Assuming we keep an area reference, really the question is should the tz group be making those decisions or not. If we should, we ought to be prepared to put up with the flak from those who differ, and also any problems where our decisions differ from those made by others. If we should not (which I think is the case) then we should use the most standardises source, e.g. ISO3166. If an exception is needed, this should purely be on the basis that ISO3166 cannot deal with the tz issues, and the reasoning for not following ISO3166 should be documented in the data file
- I think part of the intensity of the debates on various decisions has been that the rules are not well documented and transparent, but are held in a combination of files, newsgroup archives, and people's joint knowledge. If the rules are documented more rigorously and in one location, then any debate can be focussed first on does the data follow the rules and, if there is still an issue, should we change the rules for all locations instead of on a case by case basis. This will hopefully be more objective and less emotive than just "city a should be in country x and not y because it follows the beliefs of myself and some others" which is what it generally boils down to.

Tim



Smartcom Software Ltd
Portsmouth Technopole
Kingston Crescent
Portsmouth PO2 8FA
United Kingdom

www.smartcomsoftware.com

Smartcom Software is a limited company registered in England and Wales, registered number 05641521.


-----Original Message-----
From: tz-bounces at iana.org [mailto:tz-bounces at iana.org] On Behalf Of David Patte ?
Sent: 22 May 2013 19:56
To: tz at iana.org
Subject: Re: [tz] Dropping iso3166.tab

I do appreciate that my concerns on this issue have been discussed seriously. I also recognize the issue is not easy, since various product distributions may have of their own standards which must be applied to the db no matter what is decided here and by the maintainers. (I used to develop commercial word-processing products for Israel & Syria, so I am familiar with the issues). So I'll just summarize my concerns one last time, then leave it to the experts.

The tz database is used by many systems, and a lot of software, as we all know. Its usage is worldwide, and it is used in various countries and by many users, many of which may not share the same politics as the people on this list or the maintainers.

But as much as possible, this list should not be one of arguing over politics.

I totally appreciate the effort to come to a way of reducing the political debate here, or to come to a compromize that would reduce the politics from the database and list.

Removing country codes is certainly one way, and another is to consistantly use somone else's political standards as a guide (ie: the UN & ISO).

Removing country codes certainly solves the problem elegantly for the database, no more countries, no arguments of what country a city is in.

But it doesnt resolve the problem at all for those that use the database.

Unless someone knows his tz identifier offhand, a user specifying timezones will have to select it from some sort of list. Either that, or depend on the software he is using making the selection for him based on other criteria.

Herein lies my concern.

The primary way for a person to find his zone is by entering his country and city - or perhaps city alone (if he is lucky enough to guess the correct city from the long list of tz identifiers). If not the user, then someone in the implementation chain for the product will be required to do this depending on other criteria.

So, somewhere in the chain between the database and the user, someone will still have to make the decision of how to map the timezones to user-identifyable locations. If an international standard is not used in the tz database for this, then each implementer will have to decide for himself how to map each city to country - preventing the tz database from being implemented consistantly.

A user might have to choose one country to use one piece of software, and another country for another piece of software - and will not know whether his choices are consistant or correct.

So, this is my argument for using UN & ISO locations consistantly within the db. Removing international standard locations from tz will cause the implementations of the database to be fractured.

In summary:
- keeping the process as is causes endless polical debate on the mailing list - where it should not be.
- removing all countries would make the tz database far less political, but could cause fracturing of tz implementations, and difficulty implementing country-based solutions.
- using UN & ISO standards would promote standarization of the tz database and its usage, reduce debate, but unfortunately promote UN & ISO standards to those that disagree with them or their use.

I, of course prefer the third choice.