[tz] [PROPOSED] Merge timezones that are alike since 1970

[Paul Ganssle]

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?

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.

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.

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.

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 /this rule/, 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" /and it's not a violation of the rules of the list to do this/,
I don't see the value in trying to break backwards compatibility in even
small ways to be more consistent about these rules.

Best,
Paul

On 5/29/21 10:34 PM, Philip Paeps via tz wrote:
> On 2021-05-30 07:45:45 (+0800), Derick Rethans via tz wrote:
>> On 30 May 2021 00:29:28 BST, Paul Eggert via tz <tz at iana.org> wrote:
>>> On 5/29/21 1:09 PM, John Hawkinson wrote:
>>>> There is a big difference between (1) "MERGING zones across modern
>>> countries" and (2) allowing to persist "zones [that] have crossed
>>> national boundaries for decades."
>>>
>>> It's a big difference only to those closely following the history of
>>> tzdb. It's not a big difference to users.
>>
>> Referencing https://datatracker.ietf.org/doc/html/rfc6557
>>
>> 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."
>>
>> 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.
>
> 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.
>
> 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.
>
> This specific change has evolved a lot since its initial proposal.
>
> 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.
>
> Philip
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/tz/attachments/20210601/bc7a38ba/attachment.html>