[tz] [PATCH] Revert recent pre-1970 changes.
scolebourne at joda.org
Mon Sep 2 10:30:17 UTC 2013
On 2 September 2013 09:00, Paul Eggert <eggert at 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
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
- 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
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)
As such you reverted it:
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
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,
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.
More information about the tz