On Aug 31, 2013, at 4:26 PM, Stephen Colebourne <scolebourne@joda.org> wrote:

Here is the patch of reversions I would consider to be appropriate: https://github.com/jodastephen/tz/commit/86a12cbb08b28683d964f0960c6453abbd1...

Presumably - Uninhabited regions like the North Pole and Bouvet Island - do not need locations, since local time is not defined there. + Include at least one location per time zone rule set per country. + One such location is enough. Use ISO 3166 (see the file + iso3166.tab) to help decide whether something is a country. + However, uninhabited ISO 3166 regions like Bouvet Island was intended to be - Uninhabited regions like the North Pole and Bouvet Island + Include at least one location per time zone rule set per country. + One such location is enough. Use ISO 3166 (see the file + iso3166.tab) to help decide whether something is a country. + However, uninhabited ISO 3166 regions like Bouvet Island so that you don't lose "do not need locations...".

On 1 September 2013 00:51, Guy Harris <guy@alum.mit.edu> wrote:

Presumably ...> was intended to be Yes, thanks. https://github.com/jodastephen/tz/commit/47ce2bd4d2b7d2ff4f1a0f1683ca85133b6...

Stephen

On Aug 31, 2013, at 9:14 PM, Paul Eggert <eggert@cs.ucla.edu> wrote:

We should be deemphasizing political issues, not emphasizing them more.

To put it another way, the goal should be to reduce the attack surface of the tz database to non-technical complaints. There is certainly no reason to consider *increasing* the attack surface to be a good thing by itself, so, unless there's some significant benefit to increasing it, we shouldn't increase it and, unless there's some significant disadvantage to decreasing it, we should try to decrease it.

On Sep 1, 2013, at 12:57 AM, Lester Caine <lester@lsces.co.uk> wrote:

Paul Eggert wrote:

...

Stephen Colebourne wrote:

...

...

The Theory change reinstates the one zone per ISO-3166 region requirement. I'm afraid that's incorrect. That change would strengthen the requirement beyond what it ever was, by requiring a Zone to be present for every country. That has never been required and has never been the practice in the tz database.

Since the ISO-3166-1 code table is a reasonably well used base for most geographical activity, at some point timezones are required to match each.

There is no necessarily a single tzdb zone for a given entity that has an ISO 3166 code. (Two immediately obvious counterexamples - the entities with the ISO 3166 codes "US" and "CA".) So do you mean that there do not exist - or, at least, *should* not exist - any tzdb zones that apply to more than one entity with a given ISO 3166 code?

On Sep 2, 2013, at 3:19 AM, Lester Caine <lester@lsces.co.uk> wrote:

Guy Harris wrote:

...

...

Since the ISO-3166-1 code table is a reasonably well used base for most geographical activity, at some point timezones are required to match each.

There is no necessarily a single tzdb zone for a given entity that has an ISO 3166 code. (Two immediately obvious counterexamples - the entities with the ISO 3166 codes "US" and "CA".)

So do you mean that there do not exist - or, at least,*should* not exist - any tzdb zones that apply to more than one entity with a given ISO 3166 code?

Ignoring the politics ... We need to find out from our users what time zone they are in.

You need to find out from the system what time zone the user is in. For UN*X systems that sit in a machine room: Users will probably have the time zone in which that machine room resides made the default setting for their session. That time zone setting was made when the system was set up by the person who set it up. For local users, that's almost certainly the right answer, the only exceptions being users at sites sitting on time zone boundaries in offices on the other side of the time zone boundary from the machine room. For remote users, their time zone setting might be sent over the connection to the machine, although that didn't seem to be the case when I did "TZ=Europe/Berlin ssh {my machine}" - but the "Europe/Berlin" might have gone over the connection but been ignored or discarded. In those cases where the user needs to override the default, they're probably not going to be asked; instead, they're probably going to be obliged to set it themselves. For UN*X systems that sit on a desktop: Systems within an organization may well have been set up by the organization's IT department and given a default time zone setting. There is also Eliot's and Paul's DHCP option: http://tools.ietf.org/html/rfc4833 although I don't know what DHCP clients or servers support it. Personal systems will probably ask the user for the time zone when they set the system up. For UN*X systems that you can carry with you: They can often determine their location, and thus their time zone, using a combination of GPS (if available), Wi-Fi and some database of Wi-Fi networks (if available), and mobile phone tower information (if available). OS X and iOS are an existence proof of that (and, as I think iMacs come with Wi-Fi, that probably works for most OS X systems that sit on a desktop, too). If none of those *are* available, or if the user wants to override it, there's typically a way to set the time zone. I'm less familiar with Windows, but many of the answers might be similar.

Asking them 'which continent' is one of those things that gets a blank look at times, so even 'Europe' 'London' CAN be confusing to some users. Ask them 'country' and you have a much better chance of getting a response, so CA or US at least get us to a subset of options to select from? I have no problem if the detail is stored under one 'tag' so that both CA and US could use the same raw data, so 'links' to a valid set of tags should work, except would a Canadian know the correct US city? Move to the Far East, and translations become essential and there may be a need for additional 'links'?

The way the OS X "set your time zone" GUI works is that (if you don't have "Set time zone automatically using current location" checked), the world map it shows will, as you move the mouse over it, show vertical bands (probably roughly corresponding to "time zones" in the conventional sense rather than in the "tzdb zone" sense, i.e. representing default offset from GMT but *not* DST rules) and showing the countries in that zone as lighter grey. If you click on the map, it puts a blue blob at the location of the nearest city to where you clicked, changes the text for "Time Zone:" to a name for the time zone for the city, and puts the name of the city in the "Nearest City:" box. That box has a drop-down list of cities in the area (perhaps all the cities in that zone). That's how you select a tzid. The map says "Geonames.org", which is probably the source of most of the data for the map. I'm not finding an immediately-obvious indication that the GeoNames database has tzids for locations, so I'm not sure where the tzid for the location comes from. (Deborah, please feel free to step in if I got anything wrong. I didn't spend much time looking at that from down in the CoreOS engine room. :-)) So what I think "select a tzid" UIs should do is have a database such as that, and hide tzid strings from the user to the maximum extent possible. tzselect is a simple version of that, for the command line; fancier command-line tools, with fancier databases than zone.tab, could also be done. This would, ideally, involve showing people country and city *names* (rather than showing, for example, ISO 3166 country codes), in their own languages, as necessary, and would not involve people ever having to know tzids.

On Sep 2, 2013, at 11:53 AM, Lester Caine <lester@lsces.co.uk> wrote:

Guy Harris wrote:

...

This would, ideally, involve showing people country and city*names* (rather than showing, for example, ISO 3166 country codes), in their own languages, as necessary, and would not involve people ever having to know tzids.

I'm not quite sure what all this ream of writing was intended to explain?

It was intended to explain that 1) you don't always have to ask the user for the time zone - that's not a universal characteristic of everything that deals with times, as that information may be made available by other mechanisms; 2) in those cases where you *do* have to ask the user for the time zone, there are better and worse ways of doing so, and something that relies solely on the list of tzids, or that shows users tzids rather than locations, falls under the category of "worse", and you *can* do better than that (OS X does do better; I'm not sure iOS even lets you set it - as far as I know, it automatically sets the time zone using the value it gets from Core Location and some unspecified database of tzdb zone boundaries).

Setting the timezone on a local system is not the problem. It's telling some remote system what that is which is currently not happening automatically ... Yes with more modern devices we can ask for their current location, if that is enabled, but a large number of devices still don't have this facility, and my tablets don't have GPS so don't reply to a request.

Do your tablets have Wi-Fi? If so, you might be able to use something such as Skyhook: http://www.skyhookwireless.com/howitworks/ And *if* your tablets are running some OS that includes location services (iOS and Android both appear to), you might be able to use that and not even have to care how it happens.

On Sep 2, 2013, at 12:32 PM, Lester Caine <lester@lsces.co.uk> wrote:

But this is just a very small part of the use of the tz data, and my main interest is historical times, where we have the location.

"Location" in what sense? Longitude/latitude?

All I need to be able to identify is which timezone a location is in on a particular date. THIS is where the shape files defining ISO3166 codes can be useful

If you're talking about using the tzdb, and you have a location in the form of a longitude/latitude, what you want are shape files defining *tzdb zones*, not shape files defining areas labeled with ISO 3166 codes: http://efele.net/maps/tz/world/

Derick Rethans wrote:

...

OSM has a growing

...

archive of that. All I need to be able to identify is which timezone a location is in on a particular date. You mean like I've done here:

http://derickrethans.nl/what-time-is-it.html http://maps.derickrethans.nl/?l=timezone,timezones&lat=52.485&lon=-1.890&zoo...

Has it been made available as an overlay for OSM yet? You sent me a link before and I'd completely forgotten about it. I remember now what the problem was. With the rather crude outlines some edge cases are not actually covered? Holyhead for instance. It needs to be relations in OSM using the mapped country boundaries which is why I said that 'countries' was available as a search filter currently. -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

On Sep 1, 2013, at 1:55 AM, Stephen Colebourne <scolebourne@joda.org> wrote:

ISO-3166 codes are important to the vast majority of actual applications that care about time-zones.

..."care about time-zones" presumably meaning "*explicitly* care about time-zones", for example, applications that explicitly specify a time zone (whether wired in, specified as an application parameter, or specified in some configuration file or database for the application), rather than "*implicitly* care about time-zones", for example, the "date" command on UN*X systems, which cares that ctime() will convert seconds-since-the-Epoch to a string giving local time in the user's time zone, but doesn't explicitly request a particular time zone (and which has absolutely no idea what an ISO 3166 country code is, and has no reason to know).

On Sep 1, 2013, at 2:47 PM, Stephen Colebourne <scolebourne@joda.org> wrote:

On 1 September 2013 10:20, Guy Harris <guy@alum.mit.edu> wrote:

...

On Sep 1, 2013, at 1:55 AM, Stephen Colebourne <scolebourne@joda.org> wrote:

...

ISO-3166 codes are important to the vast majority of actual applications that care about time-zones.

..."care about time-zones" presumably meaning "*explicitly* care about time-zones", for example, applications that explicitly specify a time zone (whether wired in, specified as an application parameter, or specified in some configuration file or database for the application), rather than "*implicitly* care about time-zones", for example, the "date" command on UN*X systems, which cares that ctime() will convert seconds-since-the-Epoch to a string giving local time in the user's time zone, but doesn't explicitly request a particular time zone (and which has absolutely no idea what an ISO 3166 country code is, and has no reason to know).

The applications I work with and libraries I manage allow a developer to find the local time and offset from UTC/Greenwich for any instant on the timeline.

Where I'm sitting right now as I type this sentence, the local time is 4:24 PM and the offset from UTC is -7:00. Where some other members of the list, the local time is *not* 4:24 PM and the offset from UTC is *not* -7:00. Therefore, presumably either 1) the developer explicitly specifies *which particular* local time and offset they want, which is the "*explicitly* care about time zones" case or 2) the developer implicitly gets whatever local time is configured, which is the "*implicitly* cares about time zones" case. In neither case, if the tzdb is being used, does the developer for case 1) or person doing the configuration for case 2) need to specify an ISO 3166 code for the time conversion, unless the tzid isn't being specified explicitly but is instead being derived from some other values that include an ISO 3166 code. The applications in question might, for some other reason, use ISO 3166 codes, but that's a separate matter. And if you mean by "for any instant on the timeline" you mean "arbitrarily far in the past" ("arbitrarily far in the future" is only a guess unless you have an algorithm that perfectly predicts government behavior), then the real problems have nothing to do with ISO 3166 codes, they has to do with 1) the reliability of historical standardized time information in the tzdb (see, for example, per Paul's comment about Shanks); 2) the completeness of historical standardized time information in the tzdb (i.e., current tzdb zones might, in order to track standardized time rules all the way back to the introduction of standardized time, need to be split); 3) handling time *before* standardized time was introduced (which the tzdb can't and shouldn't do). 1) has nothing to do with ISO 3166 country codes. 2) doesn't really do so, either, as a zone that was always part of one and only one country might *still* get split due to, for example, local peculiarities in handling daylight savings time of which we were previously unaware.

Lester Caine <lester@lsces.co.uk> writes:

Guy Harris wrote:

...

Where I'm sitting right now as I type this sentence, the local time is 4:24 PM and the offset from UTC is -7:00.

And if I apply that offset in 6 months time will I get the right local time? How do I find what the right offset should be in 6 months time? I currently don't have enough information.

Well, just to be pendantic, no one on earth has enough information to answer that question, since it's impossible to answer. Six months time provides six months for governments to change the rules around local time, and no one knows what changes they may enact. The best that you can do is try to extrapolate forward based on current laws and hope they don't change, and recalculate local time if they do change.

Easiest way is ask for their location which usually starts with a country code and then we don't have to display the whole list of timezones ? Just a sub-set if required ... If I just ask for their 'timezone' then I still need to ask for the country anyway. Providing country code as part of the data simply helps the process of asking.

Actually, in the most recent instances when I've been asked for my time zone, I was not asked for my country. I was asked for my continent and then for the large city on that continent whose time mine matched. -- Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>

Guy Harris wrote:

...

( Wouldn't it be nice if the browser returned a timezone rather than a meaningless offset - but I've been asking that one for 10+ years:) ) To which browser are you referring? Every browser can only return your current time offset, not the actual time zone, so anything else is a guess :(

-- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

Guy Harris wrote:

...

...

...

( Wouldn't it be nice if the browser returned a timezone rather than a meaningless offset - but I've been asking that one for 10+ years:) )

...

To which browser are you referring? Every browser can only return your current time offset, not the actual time zone, so anything else is a guess:( OK, let me ask the question again: To which browser are you referring? Firefox? Internet Explorer? Safari? Chrome? Opera? Konqueror? Netscape Navigator? Mosaic? WorldWideWeb/Nexus? ...

Or, instead, let me ask the question that my expanded question indicates needs to be asked: What do you mean by "browser"?

The current 'html' standards only allow for the return of the current time offset between the local time at the site of the browser and UTC. This laughingly called the timezone Offset, but lacks that important piece of information to identify which timezone. i.e. it has no information on the daylight saving information. http://www.w3schools.com/jsref/jsref_gettimezoneoffset.asp as you will see identifies all major browsers as supporting this. It was the problems of displaying a calendar for international web based events without a client logging in which first got me involved with the tz database ... you can't display that calendar in 'local time' until the client provides their timezone manually. -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

On Sep 2, 2013, at 11:55 , Guy Harris <guy@alum.mit.edu> wrote:

On Sep 2, 2013, at 11:39 AM, Lester Caine <lester@lsces.co.uk> wrote:

...

The current 'html' standards only allow for the return of the current time offset between the local time at the site of the browser and UTC. This laughingly called the timezone Offset, but lacks that important piece of information to identify which timezone. i.e. it has no information on the daylight saving information.

OK, so you really *did* mean "browser" in the sense of "Web browser".

That's an issue for browser writers and Web standardizers; the tzdb provides tzids, whether said browser writers and Web standardizers choose to use them is up to them, not up to us (and, to a large degree, it's up to a large organization located in Redmond, Washington, USA, as they have an OS with a somewhat significant market share in the notebook, desktop, and server market, and *don't* use the tzdb for time zone/DST information, and thus any browser that runs on said OS would have to handle tzids itself rather than using OS code to do so).

The second edition of the ECMAScript Internationalization API will use IANA time zone identifiers in its DateTimeFormat API, including the ability for applications to obtain the ID of the user's time zone. That edition is currently scheduled to be finalized by December 2014, and it will be some time more before applications can rely on this functionality to be generally available in browsers. For technical details, see http://wiki.ecmascript.org/doku.php?id=globalization:specification_drafts Norbert

On Sep 2, 2013, at 10:46 AM, Stephen Colebourne <scolebourne@joda.org> wrote:

In enterpirise development both occur. There are also cases where we need to lookup the time-zone by ISO-3166.

By ISO 3166 plus something else, presumably, given that the correct answer to "what are the tzids for country codes US and CA" is "mu!"

While such a lookup (based on zone.tab) is not in JSR-310,

...and such a lookup doesn't depend on there being, for each ISO 3166 country code, at least one tzid corresponding to a location within that country; there is no *technical* reason why HR couldn't map to Europe/Belgrade. The problems with such a mapping are cultural/political, not technical; this does not mean that we can ignore those problems, it just means that they're not *technical* problems and there is no purely-*technical* requirement that, for each ISO 3166 country code, there be a tzid corresponding to a location within that country. (All problems in computer engineering can, as we know, be solved by adding a layer of indirection. :-))

Java APIs that I look after allow the user to create an object representing an instant in the far past/future. With JSR-310 that is up to 1 billion years forward and backward. Obviously, time-zones make little sense that far out, but the API is designed to make them work.

Where "work" is presumably defined to mean "always return a value rather than throwing an exception" rather than "always return a *useful* value", the latter being difficult at best for an instant preceding, say, the Big Bang. The question is "how far back should that API attempt to provide *useful* values?" If it dates back to before the government of the location for which you're trying to get local time for that instant establishing civil time as being standard time, that gets difficult, and if it dates back to before we currently have reliable information about Daylight Savings Time, it again gets difficult. *Deleting* historical information makes it more difficult, of course. So does not splitting zones if newly-discovered historical information indicates that two locations within a given tzdb zone had different standardized offsets from GMT or different DST rules. How far should the tzdb go? And should there be a way to generate, from the tzdb, a modified tzdb that coalesces all "different only before 1970" tzdb zones into a single zone? I suspect that, if we have a lot of "different only before 1970" tzids, a lot of UN*X systems will want to coalesce them, to simplify the initial time zone setup process if nothing else. And, if the Wikipedia article on ISO 3166 is correct, "The first edition of ISO 3166 was published in 1974", so ISO 3166 codes are irrelevant to the historical accuracy of pre-1970 tzdb information in any case - they're not even relevant to post-1970 but pre-1974 tzdb information. :-)

Such a decision fits well within the overall API and protects users from boundary bugs which would occur if time-zones were arbitrarily limited to a narrow range of a hundered years or so around now.

"Time zones", in the commonly understood sense, *are* limited to a narrow region of time, dating back to the establishment of said zones. I don't think there were time zones, in that sense, in 1066 CE, for example. About all you can do with a date/time going back *that* far is treat it as local mean solar time or local apparent solar time, and that involves neither time zones nor the tzdb.

On 1 September 2013 17:09, Paul Eggert <eggert@cs.ucla.edu> wrote:

Stephen Colebourne wrote:

...

...

...

...

...

The Theory change reinstates the one zone per ISO-3166 region requirement.

I'm afraid that's incorrect. That change would strengthen the requirement beyond what it ever was, by requiring a Zone to be present for every country. That has never been required and has never been the practice in the tz database.

...

You are mistaken.

Hmm, in reviewing the changes it appears we are both mistaken. The older guideline, which you are proposing to resurrect, does not require "one zone per ISO-3166 region"; it allows a link instead of a zone, and it doesn't require either for uninhabited regions. I relied on your summary of the change rather than looking at the actual wording. So when I wrote "has never been the practice", I was referring to the fact that it's always been the case that some country codes have links and not zones, while the uninhabited ones have neither.

I think we have established certain things here: - that no pre-1970 data will be deleted from any "full" zone - that LMT isn't enough reason for a separate "full" zone Given those, I have no problem with the zone ID for one ISO-3166 pointing at another, although I strongly believe that the "shared data" commentary I added is helpful to reduce pain. But I do require those links to be in the main files, not in "backward". The intention of the Theory file at that point was IMO to refer to the main database. The "backward" file is solely about backwards compatibility, an entirely different problem. The proposed patch reinstates the Theory lines, and move the Link definitions back to the main files (and not much else IIRC).

Since we do not remove names, and we already cover the inhabited ISO 3166 codes, the only reason to resurrect the older guideline would be to commit ourselves to the creation of a new link or zone in response to a new country code, or an existing one that becomes inhabited. Say, for example, the UN headquarters declares independence so the folks at ISO 3166 decide to add a code UN for the United Nations, or suppose the United States splits apart into the Red States and the Blue States. In either case, we shouldn't commit ourselves to creating new zones or links in response to these political developments. If the old names continue to work, there's no timekeeping reason to change them, and we should insulate our maintenance guidelines from politics as much as we can.

The ISO-3166 maintenance body has its own set of rules that determine when to create a new code. Such a creation is going to reflect the result of a war or some other major event. In almost all of those cases, there are going to be two sides to whatever "debate"/war was the trigger. The effect of that is that people on one side will want to separate themselves from the other. The extra zone ID thus causes less offence than the minimalist attempt you are pushing for. For example, if you remove the "backward" file today, users are expected to use Europe/Belgrade for all the ex-Yugoslav countries. If the Belgrade zone ID was a number or random sequence of letters, then that would be fine, but its not. As such, it is completely politically unacceptable for those non-Serbian peoples to be using the zone ID of the other side in a major war. Thus, I understand the desire to say "If the old names continue to work, there's no timekeeping reason to change them", but I'm afraid I find it naive when examined against real world events. And since my argument is basically to put back how this database has always worked, I feel on pretty strong ground. thanks Stephen

On 2 September 2013 09:00, Paul Eggert <eggert@cs.ucla.edu> wrote:

Stephen Colebourne wrote:

...

- LMT isn't enough reason for a separate "full" zone

In that case, there's no reason to separate America/St_Thomas from America/Tortola, right? They differ only in LMT, so they could be links.

Assuming I've googled their locations correctly, they are in two different countries. I'm just about happy to accept Europe/Zagreb -> Europe/Belgrade (in the main files), thus I'm also just about happy to accept America/St_Thomas <--> America/Tortola (in the main files, and assuming there is no other data being lost). This is an example of data sharing, not data removal. That said, given that those two IDs aren't broken and aren't causing anyone any pain, I would strongly advise just leaving them well alone. One of the key principles the tzdb should have is only to have change for enhancements. Refactoring isn't helpful for stability and causes unecessary debates like this. If it isn't broken then do not fix it.

...

if you remove the "backward" file today We are not going to remove the "backward" file. It's part of the database and is not going away. That being said, perhaps we can discuss why you have qualms about moving some of the Link directives to 'backward'. Are you trying to distinguish zone renaming from other maintenance activities? We haven't done that systematically in the past, but perhaps we should start now, if there's a reason to distinguish them.

I'm referring to how end-users preceive that file (as deprecated entries), and thus some end-user code will treat entries in that file differently from entries in the main files. That may include simply not including the "backward" file at all when they parse data (outside of zic). Here is how I believe the tzdb has worked: - the "main files" consist of all the database files except "backward" - the "main files" are standalone - all Zone/Rule/Link entries in the "main files" are complete, sensible and rational if "backward" is not processed - the "backward" file is for those IDs that have been renamed Given this, it should be no surprise that I am arguing that IDs like Europe/Zagreb should be in the main files. Currently, the zone.tab file has entries for places like Europe/Zagreb that point to the backward file. That is something I object to, and the proposed patch fixes. (There really should be checkawk-like tests to ensure that everything is correct when "backward" is excluded by end users).

...

my argument is basically to put back how this database has always worked,

First, it didn't always work the way that you described; second, when we did it that way, it led to political infighting that was unrelated to timekeeping, which is why the guideline was changed slightly. There are no timekeeping reasons to change the guideline back, only political reasons; but changing it back would lead us back into political minefields that are better avoided.

ISO-3166 has been a part of the tzdb for at least 17 years https://github.com/eggert/tz/commits/master/iso3166.tab It is as much a part of the data here as the time-zone data. Consumers of the data can and will use it to provide lookup from the most commonly used country/territory code to time-zones - a lookup that is very useful and desirable. Your commit following the Theory change included an unpopular zone.tab change that made ISO codes point at zones with names that were offensive to many (Croatia forced to use Belgrade for example) https://github.com/eggert/tz/commit/df99923bde035a263493f3435db63db15df14d53 As such you reverted it: https://github.com/eggert/tz/commit/ee40570d7d937de749fe89676dec2ff1526ee68b BUT, you only reverted a small part of the change (that to zone.tab) not the whole change. Despite having seen the measure of opposition to not respecting ISO-3166 you have continued to try to change the database - "revolution not evolution" as one commenter put it. You say "unrelated to timekeeping". I say, timekeeping *is* politics. All choices wrt what the local time is are the result of those in power and thus political. Evidence being the comments in the data files that contiinually refer to governments and decrees. You say that putting this back leads "political minefields". I say, that removing it has created the minefields. Evidence being the resistence to the commits you've been making on the back of that change, not least because of the Balkans (a minefield that would not have occurred if you had left well alone)

Here's another way to look at it. We should insulate the tz database as much as possible from political instabilities, and that includes instabilities that entail changes to ISO 3166. If we do this, the tz database will be more stable than if we don't do it. And stability is good, right?

Its an odd definition of stability that removes data, breaks connections to ISO-3166, annoys those who have recently fought wars and generally performs change that the group did not and has not provided you with the consensus to make. We need to come to closure on this. Either you're willing to revert the changes or you're not. thanks Stephen

On 3 September 2013 08:01, Paul Eggert <eggert@cs.ucla.edu> wrote:

Stephen Colebourne wrote:

...

Currently, the zone.tab file has entries for places like Europe/Zagreb that point to the backward file. That is something I object to

Well, as I said, I view that as purely an internal maintenance issue, but I can see your point of view as well. Since there are evidently real concerns about this, and since it doesn't matter that much from my point of view, I'll propose moving those Link directives back to 'northamerica' and 'southamerica'. This should be the next proposed-patch email coming from me.

Just to note that Norbert's recent email re ECMAscript locates this proposed standard: http://norbertlindenberg.com/ecmascript/intl.html#sec-6.4.2 The section explicitly uses the "backward" file to canonicalize the zone ID.

...

Refactoring isn't helpful for stability and causes unecessary debates like this.

But this is more than refactoring: it's simplification. It lessens the number of TZ settings that users need to worry about, which is a Good Thing. It lessens our exposure to future political hassles, also a Good Thing. And it shrinks the size of the binary tz data a bit, which is another win.

Personally I have no problem with changes in zic that shrink the output binary file. (In JSR-310 I have the entire tzdb in a binary form of less than 40Kb). Its the source data I'm seeking to look after. I'm being careful not to say no refactoing at all, but I'm advising that it seems that change is more of a driver of hassles than no-change.

...

ISO-3166 ... is as much a part of the data here as the time-zone data.

Maybe a bit of history here would be helpful. By design, the time-zone data are primary, and the ISO 3166 data is secondary. Arthur David Olson designed the time-zone data format originally. I designed the zone.tab and iso3166.tab formats as add-ons later, purely to help users choose TZ values; those tables were deliberately designed to be separable from the primary data, and the primary data can easily be (and often are) used without them.

Agreed that the ISO-3166 data is additional, although the Theroy rule was not. However, once something exists for so long (17 years) it becomes a core item. Stephen