Are there plans to add a time zone for Kosovo? http://en.wikipedia.org/wiki/Republic_of_Kosovo An increasing number of organizations and countries are recognizing Kosovo as a country, and having a representative zone for it would be convenient. It looks like it would be Europe/Pristina, cloned from Europe/Belgrade Thanks, -- Andy
Kosovo does not have an ISO 3166 code assigned. The historic tzdata practice has been to use ISO 3166 "to help decide whether something is a country", so that would suggest we should wait until after it is made. (If only ISO had a definition for boundaries, then we could have avoid the last big political debate). If the decision is made to proceed immediately, Wikipedia says that "XK" is the temporary code used for it by the European Commission. CLDR has also included some preliminary support for Kosovo with the code "XK". However, the last time the use of an "X" code was proposed on this list (XJ for the disputed portion of Jerusalem, or rather to simply be able to include Jerusalem in zone.tab without making any judgement on what territory it is in), it was suggested that we should avoid using user-defined codes because some program could hypothetically consume the zone.tab file while ignoring the included iso3166.tab file in favor of its own list of country codes. I don't believe this objection was substantiated, though. On Mon, May 20, 2013, at 14:01, Andy Heninger wrote:
Are there plans to add a time zone for Kosovo?
http://en.wikipedia.org/wiki/Republic_of_Kosovo
An increasing number of organizations and countries are recognizing Kosovo as a country, and having a representative zone for it would be convenient.
It looks like it would be Europe/Pristina, cloned from Europe/Belgrade
Thanks,
-- Andy
-- Random832
Unlike the status of Jerusalem vis-a-vis Israel, there has not yet been a unanimous decision by the Security Council and General Assembly concerning the independance of Kosovo. I agree it should not yet be listed as a separate country at this point. On 2013-05-20 14:26, random832@fastmail.us wrote:
Kosovo does not have an ISO 3166 code assigned. The historic tzdata practice has been to use ISO 3166 "to help decide whether something is a country", so that would suggest we should wait until after it is made. (If only ISO had a definition for boundaries, then we could have avoid the last big political debate).
If the decision is made to proceed immediately, Wikipedia says that "XK" is the temporary code used for it by the European Commission. CLDR has also included some preliminary support for Kosovo with the code "XK".
However, the last time the use of an "X" code was proposed on this list (XJ for the disputed portion of Jerusalem, or rather to simply be able to include Jerusalem in zone.tab without making any judgement on what territory it is in), it was suggested that we should avoid using user-defined codes because some program could hypothetically consume the zone.tab file while ignoring the included iso3166.tab file in favor of its own list of country codes. I don't believe this objection was substantiated, though.
On Mon, May 20, 2013, at 14:01, Andy Heninger wrote:
Are there plans to add a time zone for Kosovo?
http://en.wikipedia.org/wiki/Republic_of_Kosovo
An increasing number of organizations and countries are recognizing Kosovo as a country, and having a representative zone for it would be convenient.
It looks like it would be Europe/Pristina, cloned from Europe/Belgrade
Thanks,
-- Andy
--
On 2013-05-20 21:02, David Patte ₯ wrote:
Unlike the status of Jerusalem vis-a-vis Israel, there has not yet been a unanimous decision by the Security Council and General Assembly concerning the independance of Kosovo.
I agree it should not yet be listed as a separate country at this point.
Of course that would change if they started changing their own time zones! -- -=( Ian Abbott @ MEV Ltd. E-mail: <abbotti@mev.co.uk> )=- -=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=-
On 2013-05-21 4:58, Ian Abbott wrote:
On 2013-05-20 21:02, David Patte ₯ wrote:
Unlike the status of Jerusalem vis-a-vis Israel, there has not yet been a unanimous decision by the Security Council and General Assembly concerning the independance of Kosovo.
I agree it should not yet be listed as a separate country at this point.
Of course that would change if they started changing their own time zones!
Not necessarily. Even though Kosovo is recognized as a separate country by most western countries, the vast majority of countries (75% ?) still see it as part of Serbia pending a decision by the UN. This could all change very soon though. --
75% appears wrong, unless you are counting countries by population.
https://en.wikipedia.org/wiki/International_recognition_of_Kosovo
As you say, however, this may be a temporary situation. Mark <https://plus.google.com/114199149796022210033> * * *— Il meglio è l’inimico del bene —* ** On Tue, May 21, 2013 at 12:56 PM, David Patte ₯ <dpatte@relativedata.com>wrote:
On 2013-05-21 4:58, Ian Abbott wrote:
On 2013-05-20 21:02, David Patte ₯ wrote:
Unlike the status of Jerusalem vis-a-vis Israel, there has not yet been a unanimous decision by the Security Council and General Assembly concerning the independance of Kosovo.
I agree it should not yet be listed as a separate country at this point.
Of course that would change if they started changing their own time zones!
Not necessarily. Even though Kosovo is recognized as a separate country by most western countries, the vast majority of countries (75% ?) still see it as part of Serbia pending a decision by the UN.
This could all change very soon though.
--
<<On Mon, 20 May 2013 14:26:10 -0400, random832@fastmail.us said:
However, the last time the use of an "X" code was proposed on this list (XJ for the disputed portion of Jerusalem, or rather to simply be able to include Jerusalem in zone.tab without making any judgement on what territory it is in), it was suggested that we should avoid using user-defined codes because some program could hypothetically consume the zone.tab file while ignoring the included iso3166.tab file in favor of its own list of country codes. I don't believe this objection was substantiated, though.
FreeBSD does this (and always has); you can look at it if you want. In general we consider the ISO 3166 Maintenance Agency to be the only source of contents for that file. -GAWollman
On 05/20/13 13:59, Garrett Wollman wrote:
FreeBSD does this (and always has); you can look at it if you want.
I have been thinking of proposing to drop iso3166.tab from the tz distribution, and to drop all uses of country codes. This would help simplify maintenance, as it would mean that the database would be unaffected by political issues such as whether Kosovo is a country, what country Jerusalem is in, what country Taipei is in, etc. The idea is to simplify the database to help us focus on our charter (namely, civil time) and to be less distracted by political issues that do not affect the clocks. As part of this change, the first column of zone.tab would change from its current role (a country code) to be just a comment. I was thinking of changing the comment to be just "--", for every entry in zone.tab. How would this change affect FreeBSD's use of zone.tab?
<<On Mon, 20 May 2013 15:27:50 -0700, Paul Eggert <eggert@cs.ucla.edu> said:
I was thinking of changing the comment to be just "--", for every entry in zone.tab. How would this change affect FreeBSD's use of zone.tab?
It would completely destroy it. The tzsetup(8) utility absolutely depends on having the country codes; it would have to be rewritten to use some alternative source of country->zone mappings. -GAWollman
On Mon, 20 May 2013, Paul Eggert wrote:
On 05/20/13 13:59, Garrett Wollman wrote:
FreeBSD does this (and always has); you can look at it if you want.
I have been thinking of proposing to drop iso3166.tab from the tz distribution, and to drop all uses of country codes. This would help simplify maintenance, as it would mean that the database would be unaffected by political issues such as whether Kosovo is a country, what country Jerusalem is in, what country Taipei is in, etc. The idea is to simplify the database to help us focus on our charter (namely, civil time) and to be less distracted by political issues that do not affect the clocks.
As part of this change, the first column of zone.tab would change from its current role (a country code) to be just a comment.
I was thinking of changing the comment to be just "--", for every entry in zone.tab. How would this change affect FreeBSD's use of zone.tab?
Please don't drop it. PHP's date/time support makes use of the country codes to allow selection of possible timezones per country: http://us2.php.net/manual/en/datetimezone.listidentifiers.php cheers, Derick
On May 20, 2013, at 6:27 PM, Paul Eggert wrote:
On 05/20/13 13:59, Garrett Wollman wrote:
FreeBSD does this (and always has); you can look at it if you want.
I have been thinking of proposing to drop iso3166.tab from the tz distribution, and to drop all uses of country codes. This would help simplify maintenance, as it would mean that the database would be unaffected by political issues such as whether Kosovo is a country, what country Jerusalem is in, what country Taipei is in, etc. The idea is to simplify the database to help us focus on our charter (namely, civil time) and to be less distracted by political issues that do not affect the clocks.
I can see why this idea is attractive. I can also see why the proposal is unwelcome. Perhaps iso3166.tab can be separated out into its own distribution. If that isn't enough, maybe it can be moved into its own project. Then the trolls can do battle there with the people who want to keep that file intact, and the timezone data project itself will hopefully be rid of that noise, or at least a fair part of it. paul
Actually, in principle, I like the Mr. Eggert's concept of removing the political aspect of the distribution. There is no doubt that by associating country codes to cities, it invites political discussion since countries are political entities. And such discussions seem to make some people very uncomfortable when discussions point out incompatibilities with international political standards. But I can understand as well that most software may be using those country codes. So therefore, I would think that where possible its just simpler to follow recognize international standards (such as the UN) when improving the database. And by the way, my interest is only in making the database accessible to the most number of peopleS, no matter their political affiliation. On 2013-05-20 20:10, Paul_Koning@dell.com wrote:
Then the trolls can do battle
On 05/20/2013 06:39 PM, David Patte wrote:
I would think that where possible its just simpler to follow recognize international standards (such as the UN)
That would be simpler only in a world where there are no serious political disputes. Unfortunately this is not the world we are living in, as recent emails to this forum make clear. It's not our charter to discuss or decide these political disputes, and it'll be better if we avoid such discussions and disputes in the future.
If you mean what you just said, then I totally agree with you - 100% Thats why your mandate should be to delegate these decisions to those organizations mandated to make these decisions for us all - ie - the UN. Instead, you are playing lip-service to being apolitical - yet imposing extreme and unwarranted political views upon billions of computer users worldwide by refusing to follow world custom. Shame on you. On 2013-05-21 0:44, Paul Eggert wrote:
It's not our charter to discuss or decide these political disputes, and it'll be better if we avoid such discussions and disputes in the future.
--
On May 21, 2013, at 1:00 AM, David Patte ₯ wrote:
If you mean what you just said, then I totally agree with you - 100%
Thats why your mandate should be to delegate these decisions to those organizations mandated to make these decisions for us all
I suppose so
- ie - the UN.
Actually, no. That's not what the law says in my country. paul
To manage a database used on 1 billion machines, worldwide, across numerous political affiliations; i believe the use of international standards, such as those hashed out, diplomatically, by the UN, of which most of our countries are members, might be of some value. I can't prevent you from disagreeing with me, though, so I will await whatever random political positions you and others may try to push. But I expect you will already know my responses, so I may not answer. On 2013-05-21 12:15, Paul_Koning@Dell.com wrote:
On May 21, 2013, at 1:00 AM, David Patte ₯ wrote:
If you mean what you just said, then I totally agree with you - 100%
Thats why your mandate should be to delegate these decisions to those organizations mandated to make these decisions for us all I suppose so
- ie - the UN. Actually, no. That's not what the law says in my country.
paul
--
On Tue, May 21, 2013 at 2:39 AM, David Patte ₯ <dpatte@relativedata.com> wrote:
So therefore, I would think that where possible its just simpler to follow recognize international standards (such as the UN) when improving the database.
I generally agreed right up until there. tzinfo tries to reflect what people on the ground think. And I think country codes should reflect that. Say that Floofy (fl) and Fnord (fn) claim ownership of the large city of Fubar. I don't see anything wrong with putting Fubar in fl and fn. This way people in Floofy and Fnord see the city they expect to be there. And at the end of the day that's what tzinfo is for. In all the examples on the list there exist a large number of people who live in those places that operate under the belief that tzinfo reflects. They sign contracts, do banking, make appointments and generally live their lives in those timezones - even if they politically disagree with that belief. Reflecting reality is not the same as reflecting bureaucracy. Reflecting reality is not the same as endorsing reality. Trying to twist the tzinfo db into a tool to change reality seems like an incredibly bad idea. It should reflect what's on the ground right now, not what we might want reality to be. Kevin -- Kevin Lyda Galway, Ireland US Citizen overseas? We can vote. Register now: http://www.votefromabroad.org/
Yes, I understand that may be what you think is acceptable, but it not what those that are mandated to debate such political and diplomatic items have already decided. I have no debate about what tz people use in Jerusalem. Its the same as what people use is Tel Aviv. The concern is whether Jerusalem is recognized as an Israeli city, and it should not be up to tz to make that decision. Without delegating responsibility for what country is a country, and which city is in a country, we leave the responsibility of making these political decisions squarely within the tz list maintainer's hands, and the responsibility of running counter to accepted political decisions within their hands. This clearly opens this list open to endless political debate - which should not be the case. But by agreeing to only follow the decisions of those whose job it is to make such political decisions, the political nature of the database is delegated, and cannot be driven by the whims of the maintainers or others on this list. My goal is to reduce the political debate on this list, and leave it to the diplomats and the standards committees that are under their control, to determine what is a country, and what city is in a country - then reflect those decisions in the database. On 2013-05-21 8:49, Kevin Lyda wrote:
On Tue, May 21, 2013 at 2:39 AM, David Patte ₯ <dpatte@relativedata.com> wrote:
So therefore, I would think that where possible its just simpler to follow recognize international standards (such as the UN) when improving the database. I generally agreed right up until there. tzinfo tries to reflect what people on the ground think. And I think country codes should reflect that.
Say that Floofy (fl) and Fnord (fn) claim ownership of the large city of Fubar. I don't see anything wrong with putting Fubar in fl and fn. This way people in Floofy and Fnord see the city they expect to be there. And at the end of the day that's what tzinfo is for.
In all the examples on the list there exist a large number of people who live in those places that operate under the belief that tzinfo reflects. They sign contracts, do banking, make appointments and generally live their lives in those timezones - even if they politically disagree with that belief.
Reflecting reality is not the same as reflecting bureaucracy. Reflecting reality is not the same as endorsing reality. Trying to twist the tzinfo db into a tool to change reality seems like an incredibly bad idea. It should reflect what's on the ground right now, not what we might want reality to be.
Kevin
-- Kevin Lyda Galway, Ireland US Citizen overseas? We can vote. Register now: http://www.votefromabroad.org/
--
David Patte ??? said:
But by agreeing to only follow the decisions of those whose job it is to make such political decisions,
But who *are* those people? Taiwan and Korea are good examples here. There are politicans who believe that Taiwan is part of China, and those that don't. There are politicans who believe that Korea is one country and those who believe it is two. Then there's Cyprus. And Ireland. And .... Even deciding which politicans to follow is a political decision. -- Clive D.W. Feather | If you lie to the compiler, Email: clive@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646
On 05/21/13 08:52, Clive D.W. Feather wrote:
Then there's Cyprus. And Ireland. And ....
... and Wrangel Island. It's a good example for us, as it lies on the 180th meridian. It is controlled by Russia, whose territorial claims are acknowledged by the American government, but American Tea Party members dispute this and say that Wrangel is U.S. territory. They even dispute the name's spelling: they say it should be "Wrangell". Imagine the fun if we needed to add an entry for Wrangel/Wrangell (current population: 1) to the tz database. My sources: Sides H, Gorshkov H. Russian refuge. National Geographic (2013-05) http://ngm.nationalgeographic.com/2013/05/wrangel-island/sides-text Liberty M. Obama’s giveaway: U.S. territory to Russia Tea Party website (2013-04-28) http://www.teaparty.org/washington-ignores-russian-land-grab-of-massive-u-s-...
Kevin Lyda <kevin@ie.suberic.net> writes:
Say that Floofy (fl) and Fnord (fn) claim ownership of the large city of Fubar. I don't see anything wrong with putting Fubar in fl and fn. This way people in Floofy and Fnord see the city they expect to be there. And at the end of the day that's what tzinfo is for.
I can't imagine this would prevent anyone from disputing whether or not a given city in fact should or should not be part of, say, Floofy. Delegating our decisions to UN or other organization would shift the forum for arguing elsewhere, which presumably is mr. Eggert's motivation. Thanks, PM
On 05/20/2013 05:10 PM, Paul_Koning@Dell.com wrote:
Perhaps iso3166.tab can be separated out into its own distribution.
Thanks, that's a good idea. Let me try to flesh it out. We can do something like the following: (1) Remove iso3166.tab. Others can take up its maintenance if they like. (2) Say that zone.tab's column 1 is a comment, present only for backwards compatibility, and with no information as far as the tz database is concerned. We can describe the backward-compatibility issue in a comment, and mention that the contents of column 1 do not imply an official position or endorsement of any territorial claims. (3) Merge all Zones that are currently split only because of national boundaries. For example, merge Africa/Bangui, Africa/Brazzaville, etc., into Africa/Lagos, since these zones have all had the same clocks since 1970. We would of course retain backward-compatibility links for the merged zones, so they'd continue to work. The point of (2) is that the installers for FreeBSD, Ubuntu, etc. could continue to use zone.tab unmodified. Our installer, tzselect, can easily be modified to ignore column 1, so that we'd be eating our own dog food.
On 21 May 2013 05:34, Paul Eggert <eggert@cs.ucla.edu> wrote:
(3) Merge all Zones that are currently split only because of national boundaries. For example, merge Africa/Bangui, Africa/Brazzaville, etc., into Africa/Lagos, since these zones have all had the same clocks since 1970. We would of course retain backward-compatibility links for the merged zones, so they'd continue to work.
I think this in particular is bonkers. While politics is hard and can cause debate, its an essential part of time-zones. Time-zone rules are, by their very nature, political. States, proto-states and political areas really do matter. It should be the goal of the database, and the maintainer, to simply follow what happens with time definitions. It will necessarily involve some annoyance - which city is biggest, which area is appropriate to define the rules for - but there are other organizations like to UN and CLDR to fall back on for the politics. BTW, I still think that CLDR is a much better home for this data as they have more formal structures and certainties about managing change. Stephen
Apart from issuers with Linux, I (and I suspect quite a few hours) use the tz data in applications. I find the country code very useful in giving guidance to the extent of a time zone, and would find it a pain if it disappeared. Also, I feel that going down this route becomes the thin end of the wedge. What would we do if the Palestinians and Israelis wanted different names for the city currently known as Jerusalem, for example? Unfortunately there will always be disputes over territories. But I think the best apolitical approach to take is to follow the lead of organisations such as ISO. Those people unhappy with this should resolve it with (in this example) ISO. Otherwise we remove data from the data set that is useful to may users and not used with any political judgement, merely to satisfy the people who are unhappy with the standards and see the tz data set as an easy target to meet their aims. 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@iana.org [mailto:tz-bounces@iana.org] On Behalf Of Paul Eggert Sent: 21 May 2013 05:34 To: Paul_Koning@Dell.com Cc: tz@iana.org Subject: Re: [tz] Dropping iso3166.tab On 05/20/2013 05:10 PM, Paul_Koning@Dell.com wrote:
Perhaps iso3166.tab can be separated out into its own distribution.
Thanks, that's a good idea. Let me try to flesh it out. We can do something like the following: (1) Remove iso3166.tab. Others can take up its maintenance if they like. (2) Say that zone.tab's column 1 is a comment, present only for backwards compatibility, and with no information as far as the tz database is concerned. We can describe the backward-compatibility issue in a comment, and mention that the contents of column 1 do not imply an official position or endorsement of any territorial claims. (3) Merge all Zones that are currently split only because of national boundaries. For example, merge Africa/Bangui, Africa/Brazzaville, etc., into Africa/Lagos, since these zones have all had the same clocks since 1970. We would of course retain backward-compatibility links for the merged zones, so they'd continue to work. The point of (2) is that the installers for FreeBSD, Ubuntu, etc. could continue to use zone.tab unmodified. Our installer, tzselect, can easily be modified to ignore column 1, so that we'd be eating our own dog food.
They actually already do: Jerusalem is the English name - not the Hebrew or Arabic name. On 2013-05-21 6:03, Tim Thornton wrote:
What would we do if the Palestinians and Israelis wanted different names for the city currently known as Jerusalem, for example?
--
Yes but neither faction is saying that we should use one name in preference to the other - yet :). 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@iana.org [mailto:tz-bounces@iana.org] On Behalf Of David Patte ? Sent: 21 May 2013 12:01 To: tz@iana.org Subject: Re: [tz] Dropping iso3166.tab They actually already do: Jerusalem is the English name - not the Hebrew or Arabic name. On 2013-05-21 6:03, Tim Thornton wrote:
What would we do if the Palestinians and Israelis wanted different names for the city currently known as Jerusalem, for example?
--
Paul Eggert <eggert@cs.ucla.edu> writes:
(1) Remove iso3166.tab. Others can take up its maintenance if they like.
FWIW, I've been pointed to the following project: https://github.com/mike-fabian/langtable see in particular this file: https://raw.github.com/mike-fabian/langtable/master/data/territories.xml I'm being told that that's what Anaconda (the installer for Fedora and RHEL) should use in future. Unfortunately it lacks the "comment" part of zone.tab, and it also contains quite a bit more than zone mapping. Thanks, PM
On May 21, 2013, at 12:34 AM, Paul Eggert wrote:
On 05/20/2013 05:10 PM, Paul_Koning@Dell.com wrote:
Perhaps iso3166.tab can be separated out into its own distribution.
Thanks, that's a good idea. Let me try to flesh it out. We can do something like the following:
(1) Remove iso3166.tab. Others can take up its maintenance if they like.
(2) Say that zone.tab's column 1 is a comment, present only for backwards compatibility, and with no information as far as the tz database is concerned. We can describe the backward-compatibility issue in a comment, and mention that the contents of column 1 do not imply an official position or endorsement of any territorial claims.
(3) Merge all Zones that are currently split only because of national boundaries. For example, merge Africa/Bangui, Africa/Brazzaville, etc., into Africa/Lagos, since these zones have all had the same clocks since 1970. We would of course retain backward-compatibility links for the merged zones, so they'd continue to work.
I'd rather not do #3. The fact that they haven't had the same clocks for the entire time covered by the tzdata project isn't something that should be relegated to second class status. Also, the fact that they are under separate administration means that the clocks could easily diverge again. For example, by this argument you might have merged the entry for Venezuela with other South American entries a few years ago -- but then the administration there decided to do something different. paul
On 05/21/13 09:18, Paul_Koning@Dell.com wrote:
by this argument you might have merged the entry for Venezuela with other South American entries a few years ago -- but then the administration there decided to do something different.
I think this would still work without user problems. Suppose in 2000 we had merged America/Caracas, America/Aruba, America/Curacao, and America/Port_of_Spain. These zones would have continued to work as before, because there would be 'backward' entries. Then, in 2007, when Venezuela decided to move its clocks, we would have split the America/Caracas zone into two regions, America/Caracas and (say) America/Curacao, and all the old names would still continue to work. Splitting zones is a normal part of time zone maintenance, and this sort of thing should be routine. It's true that keeping these zones distinct insulates users from plausible future political changes -- but the downside is that there are zillions of plausible future political changes, and once we get into the business of guessing which changes are plausible enough to deserve a separate entry in the tz database, we are getting into the business of politics, which is an area we're better off avoiding.
I favor retaining the region codes, which are useful, and eliminating the endless discussions by following ISO 3166 exactly, no deviations, no discussion. On Tue, May 21, 2013 at 9:38 AM, Paul Eggert <eggert@cs.ucla.edu> wrote:
On 05/21/13 09:18, Paul_Koning@Dell.com wrote:
by this argument you might have merged the entry for Venezuela with other South American entries a few years ago -- but then the administration there decided to do something different.
I think this would still work without user problems. Suppose in 2000 we had merged America/Caracas, America/Aruba, America/Curacao, and America/Port_of_Spain. These zones would have continued to work as before, because there would be 'backward' entries. Then, in 2007, when Venezuela decided to move its clocks, we would have split the America/Caracas zone into two regions, America/Caracas and (say) America/Curacao, and all the old names would still continue to work. Splitting zones is a normal part of time zone maintenance, and this sort of thing should be routine.
It's true that keeping these zones distinct insulates users from plausible future political changes -- but the downside is that there are zillions of plausible future political changes, and once we get into the business of guessing which changes are plausible enough to deserve a separate entry in the tz database, we are getting into the business of politics, which is an area we're better off avoiding.
On Tue, May 21, 2013, at 13:03, Andy Heninger wrote:
I favor retaining the region codes, which are useful, and eliminating the endless discussions by following ISO 3166 exactly, no deviations, no discussion.
ISO 3166 does not, as far as I know, define the boundaries of the regions it names.
Paul_Koning@Dell.com said:
(3) Merge all Zones that are currently split only because of national boundaries.
I'd rather not do #3. The fact that they haven't had the same clocks for the entire time covered by the tzdata project isn't something that should be relegated to second class status. Also, the fact that they are under separate administration means that the clocks could easily diverge again.
Counter-example: most of the time zones in Europe are under a single administration (the EU). There's no significant risk from merging them (even if the SNP wins its referedum or UKIP win an election). -- Clive D.W. Feather | If you lie to the compiler, Email: clive@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646
On Tue, May 21, 2013, at 12:18, Paul_Koning@Dell.com wrote:
On May 21, 2013, at 12:34 AM, Paul Eggert wrote:
(3) Merge all Zones that are currently split only because of national boundaries. For example, merge Africa/Bangui, Africa/Brazzaville, etc., into Africa/Lagos, since these zones have all had the same clocks since 1970. We would of course retain backward-compatibility links for the merged zones, so they'd continue to work.
I should think to emphasize the magnitude of this change you should have used Europe/Copenhagen, Europe/Oslo, and Europe/Stockholm as your examples. Not sure which one you would propose using as the new timezone, though. Is there a way to programmatically generate a list of all timezones that have been the same since 1970?
I'd rather not do #3. The fact that they haven't had the same clocks for the entire time covered by the tzdata project isn't something that should be relegated to second class status.
Huh? They _have_. Before 1970 is officially not "covered by the tzdata project".
On 05/21/13 10:06, random832@fastmail.us wrote:
I should think to emphasize the magnitude of this change you should have used Europe/Copenhagen, Europe/Oslo, and Europe/Stockholm as your examples. Not sure which one you would propose using as the new timezone, though.
Whichever has the greatest population; in that case I expect it'd be Europe/Berlin. My email mentioned Africa/Lagos instead of the European examples because my process spit out names in alphabetic order, and I looked at the first entries.
Is there a way to programmatically generate a list of all timezones that have been the same since 1970?
Yes, and I've done that. Hmm, I seem to have lost the list, but I suppose I could generate it again if there's interest. (It's a bit of a pain because my program runs on Solaris but not on GNU/Linux, ouch....)
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
On May 22, 9:14pm, kre@munnari.OZ.AU (Robert Elz) wrote: -- Subject: Re: [tz] Dropping iso3166.tab | 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. FWIW, I am perfectly happy with this plan. christos
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
On 05/22/13 08:35, David Braverman wrote:
A sensible compromise. I would support 1 and 2, and agree with postponing consideration of 3.
It's certainly a lot less work to do 1 and 2 now, and postpone 3 for later. I've already done some of 3 in a private copy, but there's no urgency to finishing that task. I'm not sure I agree with the implication that 3 should be deferred indefinitely. That could well lead to more maintenance hassles, perhaps motivated by political considerations. But certainly 3 could be deferred until after 1 and 2 are done, and could be considered as a later step.
On 2013-05-22 10:14, Robert Elz wrote:
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?
That is absurd. I don't see the problem. Until recognized by the UN, the country in this case can be left as Serbia, and you simply have to choose a city in the Kosovo region of Serbia, if it is expected that the people in that city will use that time change. The country code for Kosovo is already reserved for the future, by the way. Kosovo did it long ago. And when ISO or the UN changes, then thats when to change the tz database country code. Its easy, and follows international standards. ISO 3166-1 has become one of the world’s most well known and widely used standards for coding country names. Using a code of letters and/or numbers to represent a country name can help save time and energy, and reduce the rate of error. The country codes found in ISO 3166-1 are used by many organizations, businesses and governments. For example all national postal organizations throughout the world exchange international mail in containers bearing its country code for identification. In machine readable passports, the codes from ISO 3166-1 are used to determine the nationality of the user. In addition, internet domain name systems use the codes to define top level domain names such as 'fr' for France, 'au' for Australia and 'br' for Brazil. The problem in tz is not the country code. The problem in tz is the city currently chosen in the database for certain country codes. Swapping 2 link records makes the database consistant with international standards. You sure seem like you are going to a great effeort to avoid following international standards - why?
On Wed 2013-05-22T12:07:18 -0400, David Patte hath writ:
You sure seem like you are going to a great effeort to avoid following international standards - why?
I do not see kre's proposal as a great effort. Technically it is no effort. Yes, bureaucratically it is effort, but as kre points out, international standards cannot solve the technical problems, and technical problems have always been the focus of tz. -- Steve Allen <sla@ucolick.org> WGS-84 (GPS) UCO/Lick Observatory--ISB Natural Sciences II, Room 165 Lat +36.99855 1156 High Street Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m
On Wed, May 22, 2013, at 12:37, Steve Allen wrote:
I do not see kre's proposal as a great effort. Technically it is no effort. Yes, bureaucratically it is effort, but as kre points out, international standards cannot solve the technical problems, and technical problems have always been the focus of tz.
User experience is (sort of) a technical problem. Requiring the user to select from a list of 418 time zones without providing any way to narrow it down (or from a list of 148 after only a mediocre way of narrowing it down) is a poor user experience.
Some devices have geolocation, which could allow users to select from a geographically sorted list of time zones. A graphical selection interface can allow users to select from a map based on the timezone city coordinates in zone.tab. And packagers are of course always welcome to provide more sophisticated selection mechanisms on top of the minimimal facilities offered by tz. The user experience of enabling effective time zone selection by end users is already well outside the scope of the tz project. -cott On Wed, May 22, 2013 at 10:37 AM, <random832@fastmail.us> wrote:
On Wed, May 22, 2013, at 12:37, Steve Allen wrote:
I do not see kre's proposal as a great effort. Technically it is no effort. Yes, bureaucratically it is effort, but as kre points out, international standards cannot solve the technical problems, and technical problems have always been the focus of tz.
User experience is (sort of) a technical problem. Requiring the user to select from a list of 418 time zones without providing any way to narrow it down (or from a list of 148 after only a mediocre way of narrowing it down) is a poor user experience.
-- Scott Atwood
"Some devices have geolocation, which could allow users to select from a geographically sorted list of time zones. A graphical selection interface can allow users to select from a map based on the timezone city coordinates in zone.tab. And packagers are of course always welcome to provide more sophisticated selection mechanisms on top of the minimimal facilities offered by tz. The user experience of enabling effective time zone selection by end users is already well outside the scope of the tz project." Another possibility: if the device can access a server that will give UTC, then asking "What time is it where you are now?" will give an idea of the current offset, and you can present the zones that are near that offset.
On May 22, 2013, at 10:58 AM, Scott Atwood <scott.roy.atwood@gmail.com> wrote:
Some devices have geolocation, which could allow users to select from a geographically sorted list of time zones.
s/could/do/ It worked on my previous laptop (MacBook Pro running Snow Leopard) and would, as far as I know, work on my current one (which has not yet left the Pacific time zone). (The geolocation is, I think, Wi-Fi-based, as the machine has neither a GPS receiver nor any mobile phone network connection.)
A graphical selection interface can allow users to select from a map based on the timezone city coordinates in zone.tab.
s/can/does/ Again, OS X has a world map that (if you've turned "Set time zone automatically using current location" off) shows a region boundary under the cursor; if you click on the region to select it, it offers a list of time zone names and cities in the region (a "region" appears to go from pole to pole with western and eastern boundaries). Deborah Goldsmith might know the details better than I do.
And packagers are of course always welcome to provide more sophisticated selection mechanisms on top of the minimimal facilities offered by tz. The user experience of enabling effective time zone selection by end users is already well outside the scope of the tz project.
Yup.
Guy Harris <guy@alum.mit.edu> writes:
Again, OS X has a world map that (if you've turned "Set time zone automatically using current location" off) shows a region boundary under the cursor; if you click on the region to select it, it offers a list of time zone names and cities in the region (a "region" appears to go from pole to pole with western and eastern boundaries). Deborah Goldsmith might know the details better than I do.
Ubuntu's current installer does something very similar. -- Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>
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.
On May 22, 2013, at 2:56 PM, David Patte ₯ wrote:
... 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.
Exactly. The UN certainly has view about what countries exist, or should exist, and perhaps on what their shape is. That makes one set of opinions. But not the only set, and depending on who or where you ask, not necessarily the most authoritative one. paul
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@iana.org [mailto:tz-bounces@iana.org] On Behalf Of David Patte ? Sent: 22 May 2013 19:56 To: tz@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.
On May 23, 2013, at 1:02 AM, "Tim Thornton" <tt@smartcomsoftware.com> wrote:
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'
I assume there was intended to be some more text after "so at some stage" and before the period, perhaps "...somebody needs to be able to associate a time zone with the boundary of the area to which it applies". That is what the OS X System Preferences "Date and Time" item seems to do in the "Time Zone" pane; I think at least some other OSes offer a similar mechanism. I don't know whence they get the boundary information.
- 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
At least my talk about geolocation wasn't assuming it's available, it was just suggesting that, in cases where it *is* available, that's the best default mechanism to use to select a time zone (i.e., don't even force the user to pick a region on a map, much less pick one of the arbitrary strings the tz database assigns to zones). If it's not available, obviously, that can't be done.
- 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.
Sounds good.
On Wed, 22 May 2013, Robert Elz wrote:
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.
When I started implementing support for limiting the list of returned identifiers in PHP, mostly for UI reasons, I found that I could restrict on region. A region f.e. being "America/" or "Europe/" or "Pacific/". Because that list is still way too big for people to choose from, I further restricted that on country code because the tz project conveniently provided that. Going with Paul's suggestion and removing the country codes, this is going to be broken.
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.
Right, but you will have to document them, and from a user perspective, if you're going to use some self-defined codes, then you need to document as to what they mean... which is not much difference from using the codes we use now. I'm also not happy about the instability of the tz project. It used to be for years stable. Stable IDs and a stable API. I realize there are sometimes difficult (political) issues to be debated, but *please* don't over react by just ripping things out. cheers, Derick
<<On Thu, 23 May 2013 13:43:25 -0700 (PDT), Derick Rethans <tz@derickrethans.nl> said:
When I started implementing support for limiting the list of returned identifiers in PHP, mostly for UI reasons, I found that I could restrict on region. A region f.e. being "America/" or "Europe/" or "Pacific/". Because that list is still way too big for people to choose from, I further restricted that on country code because the tz project conveniently provided that.
FreeBSD's tzsetup(8) utility does the same thing for pretty much the same reason. -GAWollman
On 05/20/2013 06:27 PM, Paul Eggert wrote:
I have been thinking of proposing to drop iso3166.tab from the tz distribution, and to drop all uses of country codes.
As part of this change, the first column of zone.tab would change from its current role (a country code) to be just a comment. So how is tzselect going to work?
Is tz no longer going to provide reference code for a user-friendly way to select time zones?
On 05/20/2013 06:42 PM, Random832 wrote:
So how is tzselect going to work?
tzselect will still work. It will skip the part where it asks "Please select a country". So its menu will get shallower and bushier. The code to skip "Please select a country" is already in tzselect, and has been for many years. If zone.tab's column 1 is changed to be a comment, we can simplify tzselect to automatically skip the question rather than to calculate whether the question can be skipped.
On Tue, May 21, 2013, at 0:14, Paul Eggert wrote:
On 05/20/2013 06:42 PM, Random832 wrote:
So how is tzselect going to work?
tzselect will still work. It will skip the part where it asks "Please select a country". So its menu will get shallower and bushier.
The code to skip "Please select a country" is already in tzselect, and has been for many years.
The current code only skips the question if it _only has one possible answer_ - a code path that I don't think even ever gets exercised now.
If zone.tab's column 1 is changed to be a comment, we can simplify tzselect to automatically skip the question rather than to calculate whether the question can be skipped.
The descriptions in column 4 are not adequate, without a country, to select a time zone. You would basically have to add the country to it. I don't see why you're going for this nuclear option when the issue could have been resolved simply by replacing Asia/Jerusalem with Asia/Tel_Aviv in zone.tab with _no_ data changes (and for heaven's sake, nobody was arguing about Taiwan... except the anti-change people using it to draw a false equivalency).
Random832, this is tounge-in-cheek, but ... On Tue, May 21, 2013 at 8:44 PM, <random832@fastmail.us> wrote:
(and for heaven's sake, nobody was arguing about Taiwan... except the anti-change people using it to draw a false equivalency).
First they changed McQuarie in Australia, and I can't even spell it Then they came for Jerusalem, and I have never visted it Then they will come for Taiwan, and I do not stay there, so I was silent ... -- Sanjeev Gupta +65 98551208 http://www.linkedin.com/in/ghane
Paul Eggert wrote:
I have been thinking of proposing to drop iso3166.tab from the tz distribution, and to drop all uses of country codes. This would help simplify maintenance, as it would mean that the database would be unaffected by political issues such as whether Kosovo is a country,
The association of time zones with countries is useful, despite the somewhat fuzzy and occasionally contentious nature of country boundaries. It is, of course, entirely proper that the notion of "country" doesn't influence the zone naming scheme, for many more reasons than any present controversy about country status. Segregating the country/zone link data into a separate file, with its own update mechanism, was a wise choice. Although affected by politics, the database is substantially *insulated from* the politics, by virtue of delegating the decision on what is a country to the ISO 3166 MA. I don't see it being a significant problem. -zefram
On May 21, 11:37am, zefram@fysh.org (Zefram) wrote: -- Subject: Re: [tz] Dropping iso3166.tab | Paul Eggert wrote: | >I have been thinking of proposing to drop iso3166.tab from the | >tz distribution, and to drop all uses of country codes. | >This would help simplify maintenance, as it would mean | >that the database would be unaffected by political | >issues such as whether Kosovo is a country, | | The association of time zones with countries is useful, despite the | somewhat fuzzy and occasionally contentious nature of country boundaries. | It is, of course, entirely proper that the notion of "country" doesn't | influence the zone naming scheme, for many more reasons than any present | controversy about country status. Segregating the country/zone link data | into a separate file, with its own update mechanism, was a wise choice. I totally agree. We should not remove the country-timezone association; it has been there for a long time and it is useful. The iso3166 list of countries is the de-facto standard used everywhere (in website list of countries for example). Ignoring it does not make us apolitical, it makes us bending over the pressure from a few highly politically-biased semi-anonymous folks. christos
Zefram said:
Although affected by politics, the database is substantially *insulated from* the politics, by virtue of delegating the decision on what is a country to the ISO 3166 MA. I don't see it being a significant problem.
However, please note that ISO 3166 does not define a country. There are countries (notably France) that have several codes. ISO says: "The country names in ISO 3166 come from United Nations sources. New names and codes are added automatically when the United Nations publishes new names in either the Terminology Bulletin Country Names or in the Country and Region Codes for Statistical Use maintained by the United Nations Statistics Divisions." -- Clive D.W. Feather | If you lie to the compiler, Email: clive@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646
On Mon, May 20, 2013 at 11:27 PM, Paul Eggert <eggert@cs.ucla.edu> wrote:
On 05/20/13 13:59, Garrett Wollman wrote:
FreeBSD does this (and always has); you can look at it if you want.
I have been thinking of proposing to drop iso3166.tab from the tz distribution, and to drop all uses of country codes. This would help simplify maintenance, as it would mean that the database would be unaffected by political issues such as whether Kosovo is a country, what country Jerusalem is in, what country Taipei is in, etc. The idea is to simplify the database to help us focus on our charter (namely, civil time) and to be less distracted by political issues that do not affect the clocks.
As part of this change, the first column of zone.tab would change from its current role (a country code) to be just a comment.
The Python timezone library (pytz, currently standalone but accepted to be included into Python core) exposes a mapping of iso3166 country code to timezones in use in that region. This is currently pulled from zone.tab. Removing this information from zone.tab without an alternative would break an unknown number of Python applications. If zone.tab has political problems, could we maintain this information in another format? I don't see that a list of which timezones are in use in a region is at all political - Asia/Taiwan for instance could happily be listed both for .tw and .cn. This would satisfy the pytz use cases, as well as other systems needing a cheap mechanism for narrowing down timezone selection choices. -- Stuart Bishop <stuart@stuartbishop.net> http://www.stuartbishop.net/
On Thu, May 23, 2013, at 10:42, Stuart Bishop wrote:
If zone.tab has political problems, could we maintain this information in another format? I don't see that a list of which timezones are in use in a region is at all political - Asia/Taiwan for instance could happily be listed both for .tw and .cn. This would satisfy the pytz use cases, as well as other systems needing a cheap mechanism for narrowing down timezone selection choices.
Back on the subject of Jerusalem... While looking up some information about ISO 3166 for background for this discussion, I noticed that ISO 3166-2 lists "Jerusalem" regions for both countries: IL-JM and PS-JEM. If we _must_ list Jerusalem in zone.tab (rather than simply using Tel_Aviv and Ramallah, respectively, which I still think is the best solution as it simply avoids making any comment), maybe it should therefore be listed in both. (ISO 3166-2 also lists Taiwan as CN-71, though it does not list the mainland territories administered by the PRC under TW - this would suggest listing Asia/Taipei under both countries, but not Asia/Beijing.)
Android uses this zone.tab column in multiple places (but all for the purposes of knowing what time zones are most relevant for a given country code). On Mon, May 20, 2013 at 3:27 PM, Paul Eggert <eggert@cs.ucla.edu> wrote:
On 05/20/13 13:59, Garrett Wollman wrote:
FreeBSD does this (and always has); you can look at it if you want.
I have been thinking of proposing to drop iso3166.tab from the tz distribution, and to drop all uses of country codes. This would help simplify maintenance, as it would mean that the database would be unaffected by political issues such as whether Kosovo is a country, what country Jerusalem is in, what country Taipei is in, etc. The idea is to simplify the database to help us focus on our charter (namely, civil time) and to be less distracted by political issues that do not affect the clocks.
As part of this change, the first column of zone.tab would change from its current role (a country code) to be just a comment.
I was thinking of changing the comment to be just "--", for every entry in zone.tab. How would this change affect FreeBSD's use of zone.tab?
participants (27)
-
Andy Heninger -
Andy Lipscomb -
christos＠zoulas.com -
Clive D.W. Feather -
David Braverman -
David Patte ₯ -
Derick Rethans -
enh -
Garrett Wollman -
Guy Harris -
Ian Abbott -
Kevin Lyda -
Mark Davis ☕ -
Paul Eggert -
Paul_Koning＠Dell.com -
Petr Machata -
Random832 -
random832＠fastmail.us
-
Robert Elz -
Russ Allbery -
Sanjeev Gupta -
Scott Atwood -
Stephen Colebourne -
Steve Allen -
Stuart Bishop -
Tim Thornton -
Zefram