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