<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>I'm not entirely clear on the current status of the proposal. If
most people are getting all the data from `backzone` anyway and
the data is still being maintained in the repository, does this
really alleviate the maintenance burden? Is the idea that the tzdb
project will stop accepting patches to `backzone`, and thus these
are frozen in amber?<br>
<br>
I suspect that if this is invisible to the end user, it will not
keep people from reporting bugs or complaining about what they
feel the key structure should be, and if anything it will increase
bugs, because if they use a system that doesn't link in backzone,
they'll be very confused about why previously valid keys are no
longer valid.<br>
<br>
I'll note that I'm not against the proposal and I certainly don't
think that it should be stopped because it would merge zones
across country boundaries — I don't think there needs to be a
notion of countries in the tzdb any more than there needs to be a
notion of specific cities, I just want to know what we're supposed
to be getting for the change.<br>
<br>
Personally, I agree with ado about maintaining the old funky
pre-1970 zones (or at least keeping them present in the database
as-is, indefinitely) for the purposes of stress-testing the
capabilities of the tzdb. I make fairly extensive use of pre-1970
zones in my various TZif parsing libraries (e.g. Python's dateutil
and zoneinfo) because that's where you get weird stuff like double
daylight saving time, large swings in offset and fractional-minute
offsets.<br>
<br>
At the end of the day, I think the main problem that this is
addressing is that Paul wants to have some consistency in the
rules so that he can point to the rule and say, "Here's the rule
we're using, please tell us if there's a violation of <i>this
rule</i>, otherwise we don't want to engage." But the problem is
that we already have this for the most contentious stuff and it's
not really enforced. The conversation instead goes, "Here's the
rule we're using" and the follow up is, "That's a stupid rule, you
should change it." then a bunch of people pile on in both sides
and no time is saved. If that's going to happen anyway and every
time anyone shows up and complains about the rules a dozen people
are going to pile on saying, "We should change the zone names to
non-human-readable alphanumeric keys" or "We should make one zone
per country" <i>and it's not a violation of the rules of the list
to do this</i>, I don't see the value in trying to break
backwards compatibility in even small ways to be more consistent
about these rules.<br>
<br>
Best,<br>
Paul<br>
</p>
<div class="moz-cite-prefix">On 5/29/21 10:34 PM, Philip Paeps via
tz wrote:<br>
</div>
<blockquote type="cite"
cite="mid:87198D86-2C15-447C-BB86-7F0A2999EED3@trouble.is">On
2021-05-30 07:45:45 (+0800), Derick Rethans via tz wrote:
<br>
<blockquote type="cite">On 30 May 2021 00:29:28 BST, Paul Eggert
via tz <a class="moz-txt-link-rfc2396E" href="mailto:tz@iana.org"><tz@iana.org></a> wrote:
<br>
<blockquote type="cite">On 5/29/21 1:09 PM, John Hawkinson
wrote:
<br>
<blockquote type="cite">There is a big difference between (1)
"MERGING zones across modern
<br>
</blockquote>
countries" and (2) allowing to persist "zones [that] have
crossed
<br>
national boundaries for decades."
<br>
<br>
It's a big difference only to those closely following the
history of
<br>
tzdb. It's not a big difference to users.
<br>
</blockquote>
<br>
Referencing <a class="moz-txt-link-freetext" href="https://datatracker.ietf.org/doc/html/rfc6557">https://datatracker.ietf.org/doc/html/rfc6557</a>
<br>
<br>
Dear Paul, you've had a lot of push back to this change, as per
the "Procedures for Maintaining the Time Zone Database" the TZ
Coordinator "SHOULD take into account views expressed on the
mailing list."
<br>
<br>
I would very much appreciate it if you'd at least listen to the
feedback you've gotten on this change, and I'd argue that from
what I've read, that this list is not OK with this proposed
change.
<br>
</blockquote>
<br>
One of the things I like a lot about the tzdb project is the
spirited discussions we have on this mailing list about proposed
changes.
<br>
<br>
Anyone who has been subscribed to the list for a while (or who
spends some time reading the archives) will be aware that feedback
is indeed taken into account.
<br>
<br>
This specific change has evolved a lot since its initial proposal.
<br>
<br>
It's also worth pointing out again to those unfamiliar with the
way tzdb is usually distributed (e.g in operating systems
distributions), that Paul's proposed change is largely invisible
to most users. Most tzdb downstreams link in backzone. Data is
merely being moved to a different place. It's not actually being
removed.
<br>
<br>
Philip
<br>
<br>
</blockquote>
</body>
</html>