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.
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)
OK, I'll propose a change along these lines as well. That'll be in a followon patch email.
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.
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.