Paul Goyette via tz <tz@iana.org> writes:

On Tue, 21 Sep 2021, Stephen Colebourne via tz wrote:

...

Is there consensus on the list that a change is required?

I do NOT believe that a change is required.

Likewise, I don't believe a change is required. -- Russ Allbery (eagle@eyrie.org) <https://www.eyrie.org/~eagle/>

The primary division would be current iso countries.And there is no need to go back as far as you suggest. LMT, as I'm sure you are aware, originated as standard in many cities in the 1800 due to clock technology. Before that most people used local solar (sundial) time.Sent from my Galaxy -------- Original message --------From: Steve Allen via tz <tz@iana.org> Date: 2021-09-21 18:40 (GMT-05:00) To: Time Zone Database discussion <tz@iana.org> Subject: Re: [tz] Replacing the TZ Coordinator On Tue 2021-09-21T22:42:47+0100 Stephen Colebourne via tz hath writ:> Is there consensus on the list that a change is required?No.Before a change of coordinator happens I want to see proponents of"one zone per ISO country code" and proponents of the "data before1970 must be available" agree on how tzdata and tzcode should handlethis:https://www.euratlas.net/history/europe/1600/--Steve Allen                    <sla@ucolick.org>              WGS-84 (GPS)UCO/Lick Observatory--ISB 260  Natural Sciences II, Room 165  Lat  +36.998551156 High Street               Voice: +1 831 459 3046         Lng -122.06015Santa Cruz, CA 95064           https://www.ucolick.org/~sla/  Hgt +250 m

I do not believe we have got to that stage. That said, I also believe we should hold off on any major changes until we have a clear consensus. I think an appropriate course of action would be to revert to 2021a, apply the changes just announced, and then everyone take a week off to think about things and to calm down. After we've all taken a week's break let's all put together the various proposals in a single list, and work out which is the right one (if any) to go forward with. -Rob Robert Masters On 9/21/21 17:42, Stephen Colebourne via tz wrote:

The TZDB project is guided by RFC 6557. Section 4 allows the list to seek an alternate TZ coordinator where "The TZ Coordinator is not performing the function in accordance with community wishes". https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc6557.htm l*section-4__;Iw!!O7oHvdjpjIQ!kM6ZNHhCWnmLkZH2xxPctTn67pvsqSctoUcYUKVD kNkF_p6RkOKH45-3G2URdtxH-A$

The RFC instructs as follows:

Members of the community should raise the issue on the TZ mailing list and attempt to reach consensus on a new candidate to fulfill the role of TZ Coordinator. If rough consensus cannot be reached easily, the Area Directors of the IETF Applications Area should attempt to guide the members of the community to rough consensus. The candidate that is agreed upon by the community through rough consensus shall be presented to the IESG for confirmation. If rough consensus cannot be reached, even with guidance from the Applications Area Directors, the IESG shall use whatever means it has at its disposal to choose a candidate who in its best judgment will be able to fulfill the role of TZ Coordinator.

Is there consensus on the list that a change is required? Is there a candidate willing to take on the role of TZ Coordinator?

Stephen

********************************************************************** This email is confidential and may contain legally privileged information. If you are not the intended recipient, you must not disclose or use the information contained in it. If you have received this email in error, please notify us immediately by return email and delete the document

On 22 September 2021 03:08:00 BST, Robert Masters via tz <tz@iana.org> wrote:

I do not believe we have got to that stage. That said, I also believe we should hold off on any major changes until we have a clear consensus.

I think an appropriate course of action would be to revert to 2021a, apply the changes just announced, and then everyone take a week off to think about things and to calm down.

After we've all taken a week's break let's all put together the various proposals in a single list, and work out which is the right one (if any) to go forward with.

I wholeheartedly agree with that. I don't want a fork, I don't want to replace anybody. What I do want is a consensus seeking process to change away from a status quo. For me, that status quo is currently the 2021a release. If anybody, including the TZ Coordinator, wants to deviate from that status quo, a consensus should be reached *before* implementing such a change. As a data consumer, stability of the default output of zic is paramount. cheers Derick

To the extent I'm allowed, I vote No. We're having a good debate, and AFAICT both sides have merit. The TZDB is and has always been a creature of the Linux epoch; pre-1970 times and dates are, legitimately, outside its remit. But software evolves in ways that don't always fit the pure ideals of its creators; the TZDB has become the best source available for historical time zone information. I would ask this of the coordinators, though: can someone summarize as dispassionately as possible what the proposals are, and what the pros and cons of each are? Or maybe one person from each camp? We're all software engineers (or software-engineer-adjacent). We can fix this. David Braverman

The TZDB project is guided by RFC 6557. Section 4 allows the list to seek an alternate TZ coordinator where "The TZ Coordinator is not performing the function in accordance with community wishes". https://www.rfc-editor.org/rfc/rfc6557.html#section-4

The RFC instructs as follows:

Members of the community should raise the issue on the TZ mailing list and attempt to reach consensus on a new candidate to fulfill the role of TZ Coordinator. If rough consensus cannot be reached easily, the Area Directors of the IETF Applications Area should attempt to guide the members of the community to rough consensus. The candidate that is agreed upon by the community through rough consensus shall be presented to the IESG for confirmation. If rough consensus cannot be reached, even with guidance from the Applications Area Directors, the IESG shall use whatever means it has at its disposal to choose a candidate who in its best judgment will be able to fulfill the role of TZ Coordinator.

Is there consensus on the list that a change is required? Is there a candidate willing to take on the role of TZ Coordinator?

Stephen

Having been engaged with date and time standards, my insignificant comment here is that I believe Paul has done everything intended to benefit the tz community, I wish he stays on, and there is no consensus for seeking an alternative TZ coordinator. _____________________________________ Ronald Tse Ribose Inc. On 9/21/21 17:42, Stephen Colebourne via tz wrote: The TZDB project is guided by RFC 6557. Section 4 allows the list to seek an alternate TZ coordinator where "The TZ Coordinator is not performing the function in accordance with community wishes". https://www.rfc-editor.org/rfc/rfc6557.html#section-4 The RFC instructs as follows: Members of the community should raise the issue on the TZ mailing list and attempt to reach consensus on a new candidate to fulfill the role of TZ Coordinator. If rough consensus cannot be reached easily, the Area Directors of the IETF Applications Area should attempt to guide the members of the community to rough consensus. The candidate that is agreed upon by the community through rough consensus shall be presented to the IESG for confirmation. If rough consensus cannot be reached, even with guidance from the Applications Area Directors, the IESG shall use whatever means it has at its disposal to choose a candidate who in its best judgment will be able to fulfill the role of TZ Coordinator. Is there consensus on the list that a change is required? Is there a candidate willing to take on the role of TZ Coordinator? Stephen

On Wed, 22 Sept 2021 at 03:54, Eliot Lear via tz <tz@iana.org> wrote:

I'm not saying there isn't room for improvement in this process, but it is far better to work the issue respectfully and patiently, recognizing that there are divergent views and needs.

I and others have spent months trying to get this reverted. There hasn't been the slightest indication that Paul comprehends why his actions are unacceptable and nonsensical. There has been absolutely no willingness to revert despite repeated requests from numerous people/groups. You ask for work on the issue to be respectfully and patiently conducted, but that isn't something I can do with 2021b pending. It is just like a loaded gun being pointed at my head. As others have said, the right course of action is to revert to 2021a and draw up proper proposals for the future. I am absolutely certain that a solution can be found. Stephen

+1 on both points. On 9/22/21 5:05 AM, Philip Paeps via tz wrote:

No. I do not believe that a change is required.

I support the suggestion elsewhere in this thread that we revert to 2021a, apply the non-controversial changes and take a week off to cool down.

Philip

-- Kenneth Murchison Senior Software Developer Fastmail US LLC

+1 from me as well. Deborah

On Sep 22, 2021, at 7:09 AM, Mark Davis ☕️ via tz <tz@iana.org> wrote:

+1

On Wed, Sep 22, 2021, 04:11 Ken Murchison via tz <tz@iana.org <mailto:tz@iana.org>> wrote: +1 on both points.

On 9/22/21 5:05 AM, Philip Paeps via tz wrote:

...

No. I do not believe that a change is required.

I support the suggestion elsewhere in this thread that we revert to 2021a, apply the non-controversial changes and take a week off to cool down.

Philip

-- Kenneth Murchison Senior Software Developer Fastmail US LLC

On 9/22/21 11:06 AM, Stephen Colebourne via tz wrote:

Paul, as duly endorsed TZ Coordinator, are you willing to accept the proposed action to allow time and space to come up with a proper solution?

Unfortunately, the equity issue has broadened and is now visible outside our little community, and I really and sincerely doubt whether it'd be a good idea for us to do nothing about it now. We need to establish that we are fixing the problem and are not deferring action to a never-never land of arcane bureaucracy, and we need to do so in terms that will be clear to outsiders. So, instead of the 2021a1-vs-2021b compromise I suggested earlier (which turns out to have important compatibility issues just with the name "2021a1"!) I now plan to compromise along the lines I suggested a dozen hours ago, here: https://mm.icann.org/pipermail/tz/2021-September/030686.html I.e., the idea is to revert most (but not all) of the objected-to changes. In particular, this will revert the changes to Europe/Oslo and Europe/Stockholm, which have drawn the most objections. The idea is to take the first step now, and to take more steps in future releases (which should not be distant-future releases, as we need to continue to make and exhibit a good-faith effort to fix the problem). This will let us generate just one version, 2021b. Although your followup <https://mm.icann.org/pipermail/tz/2021-September/030689.html> didn't agree with the proposed compromise, it didn't reject it in quite the strong terms that I saw in earlier emails. And indeed, the proposed compromise is far closer to what you suggested than to what I suggested, as it replaces only 9 Zones with Links instead of 30-odd Zones. So it's a reasonable way forward, even if both of us dislike the compromise. Because this proposal is a reversion, it should be safe even though it's a last-minute change.

Now that 2021b has been released containing changes that nearly the entire list was opposed to releasing at this point in time, are we certain this is the correct choice? I believe the combination of blatantly ignoring a near-unanimous majority of users, ignoring the real-world impacts of the changes, and actively insulting and demeaning users is sufficient reason to replace the coordinator. Jacob Pratt On Fri, Sep 24, 2021, 18:27 Stephen Colebourne via tz <tz@iana.org> wrote:

On Fri, 24 Sept 2021 at 23:12, Paul Eggert <eggert@cs.ucla.edu> wrote:

...

On 9/22/21 11:06 AM, Stephen Colebourne via tz wrote: So, instead of the 2021a1-vs-2021b compromise I suggested earlier (which turns out to have important compatibility issues just with the name "2021a1"!) I now plan to compromise along the lines I suggested a dozen hours ago, here:

https://mm.icann.org/pipermail/tz/2021-September/030686.html

I.e., the idea is to revert most (but not all) of the objected-to changes. In particular, this will revert the changes to Europe/Oslo and Europe/Stockholm, which have drawn the most objections. The idea is to take the first step now, and to take more steps in future releases (which should not be distant-future releases, as we need to continue to make and exhibit a good-faith effort to fix the problem). This will let us generate just one version, 2021b.

Although your followup <https://mm.icann.org/pipermail/tz/2021-September/030689.html> didn't agree with the proposed compromise, it didn't reject it in quite the strong terms that I saw in earlier emails. And indeed, the proposed compromise is far closer to what you suggested than to what I suggested, as it replaces only 9 Zones with Links instead of 30-odd Zones. So it's a reasonable way forward, even if both of us dislike the compromise.

No. No, no, no.

I've talked about Oslo and Stockholm as examplars - I reject the whole concept of link merging without a bigger plan. Merging ANY zones in major world business centres will immediately impact any Joda-Time user that updates their time-zone data themselves.

9 changes instead of 30 changes is not helpful. The way out of this mess is zero merges today and a rational discussion next week.

Stephen

Paul Eggert via tz said:

Unfortunately, the equity issue has broadened and is now visible outside our little community, and I really and sincerely doubt whether it'd be a good idea for us to do nothing about it now. We need to establish that we are fixing the problem and are not deferring action to a never-never land of arcane bureaucracy, and we need to do so in terms that will be clear to outsiders.

Paul, I don't recall this "equity" issue being raised on the list until the current set of threads. You say it's been going on for several years, and I don't doubt that, but I don't recall any of it. You say here that it's "visible outside our little community" and you said in another email that you'd been receiving emails on the topic. Perhaps it would help if you could share with us some of these emails or other messages that indicate the presence of a problem and exactly what the problem is as seen by outsiders/lurkers. At present it's obvious that the meaning of "equity" isn't agreed by the whole list. You clearly have a meaning in your head, and also think that you're required to act in accordance with that meaning. A clearer statement of the meaning and examples of what these others think is the issue would help the debate going forward. -- Clive D.W. Feather | If you lie to the compiler, Email: clive@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646

Paul Eggert said:

On 9/25/21 3:14 PM, Clive D.W. Feather wrote:

...

I don't recall this "equity" issue being raised on the list until the current set of threads.

The wording was less direct (and without the "equity" buzzword) earlier this year, when the request to add a Kosovo entry was made. It was that request that inspired the cleanup proposal I made in May.

...

You say it's been going on for several years

Although the equity issue has been present for years in tzdb, it wasn't considered to be a significant problem until Kosovo came up.

Thank you for that. However, that was an introduction to the main point of my email, which you haven't answered:

...

You say here that it's "visible outside our little community" and you said in another email that you'd been receiving emails on the topic.

Perhaps it would help if you could share with us some of these emails or other messages that indicate the presence of a problem and exactly what the problem is as seen by outsiders/lurkers.

At present it's obvious that the meaning of "equity" isn't agreed by the whole list. You clearly have a meaning in your head, and also think that you're required to act in accordance with that meaning. A clearer statement of the meaning and examples of what these others think is the issue would help the debate going forward.

-- Clive D.W. Feather | If you lie to the compiler, Email: clive@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646

On 9/26/21 10:12 AM, Paul Eggert via tz wrote:

I thought it was understood that the guidelines are intended to be applied fairly. If I was wrong, and some readers mistakenly think that it's OK to apply the guidelines unfairly, then we should modify the guidelines to make this understanding clearer.

In rereading this I see that I was perhaps a bit too sarcastic. Better wording would have been "if some readers disagree about what constitutes fairness", or something like that.

On 9/26/21 10:24 AM, Clive D.W. Feather wrote:

Could you provide pointers, please, rather than asking us to search without any clues.

Listing precise pointers would take some work. Here's a clue instead: Google "Kosovo site:icann.org". There are quite a few hits going back many years. Although I distinctly recall a conversation about it within the past year, perhaps that conversation was all or mostly private. Whatever part was public, should have been archived at ICANN.

The problem is what "fairly" means.

Yes. Stephen has said he'd like to write something up addressing that issue, and we have time to think about how the guidelines should say that the guidelines should be applied fairly. I see no need for me to propose something right this minute, and there is value in letting things cool off a bit.

...

...

It's not just in my head; it's written down in the guidelines (see theory.html).

A quote here would be useful.

"If all the clocks in a timezone have agreed since 1970, do not bother to include more than one timezone even if some of the clocks disagreed before 1970." https://www.ietf.org/timezones/tzdb-2021b/theory.html#naming