Replacing the TZ Coordinator
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
While only a casual follower of the mailing list, I personally believe a change is necessary. Jacob Pratt On Tue, Sep 21, 2021, 17:43 Stephen Colebourne via tz <tz@iana.org> 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 Tue, 21 Sep 2021, 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?
I do NOT believe that a change is required. +--------------------+--------------------------+----------------------+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | paul@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoyette@netbsd.org | | | | pgoyette99@gmail.com | +--------------------+--------------------------+----------------------+
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/>
On Tue, Sep 21, 2021 at 10:42:47PM +0100, 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?
No, such a change is definitely not required. Also, those who are going to fork tzdb in their projects should understand they are adding additional work to distro maintainers who would have to patch their fork out. -- ldv
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 before 1970 must be available" agree on how tzdata and tzcode should handle this: 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.99855 1156 High Street Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 https://www.ucolick.org/~sla/ Hgt +250 m
Steve Allen via tz <tz@iana.org> writes:
Before a change of coordinator happens I want to see proponents of "one zone per ISO country code" and proponents of the "data before 1970 must be available" agree on how tzdata and tzcode should handle this: https://www.euratlas.net/history/europe/1600/
That's really quite an unfair line of argument: it's not like we have solutions to those problems in the current state of tzdb, nor did the May changes move us closer to having such solutions. FWIW, I'm not particularly set on either of the viewpoints you mention above. What I *am* interested in is a conservative approach to management of the tzdb data, which I would define as not changing historical data for any zone except when there is reasonable evidence that the new data is more accurate than the old. The May changes completely failed to consider this point, and instead saddled individual tzdb repackagers with the need to decide which set of inaccurate data they'd rather ship. regards, tom lane
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
No 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
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
Robert Masters via tz said:
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.
That sounds eminently sensible to me. -- 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 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
On Wed, Sep 22, 2021 at 4:54 PM Derick Rethans via tz <tz@iana.org> wrote:
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.
Yes please. There is no consensus to make the change, there is no consensus (I think) to change the Coordinator, or do anything else. My issue is that I have not seen any justification for merging Oslo into Berlin, other than some non-European (like me) finds it offensive. But even as I would like my village in Punjab to have its own entry, it hurts me not at all that the Vikings have one too. Paul has done excellent, and thankless, and backbreaking regular work to get us here. And he does bring up good points on this change. But I posit this: this is a significant change to the data, and *that* requires a consensus, I would say. Which is not what has happened. Please do not mix up the Oslo change with the Apia change. We are agreed on Apia, let that proceed, and let us continue to work out the other issue. Who knows, the fifteenth time we might agree with each other :-) Paul, I understand that a significant time is spent explaining repeatedly why one City has a zone of its own, and not another (Hi, Kiev). But I do not think that that problem is solved by excluding everyone, just because we cannot include some of us. And I don't see how the Kiev emails will stop after this change, anyway. -- Sanjeev Gupta +65 98551208 http://www.linkedin.com/in/ghane
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
On Sep 21, 2021, at 7:14 PM, David Braverman via tz <tz@iana.org> wrote:
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.
(Linus Torvalds was less than year old during most of 1970; presumably you meant "UN*X epoch" or "POSIX epoch" or something such as that.)
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
No, and you need to stop throwing a tantrum. This group has existed for decades, and much of the work to maintain both the database and the code was done by Paul. The level of disrespect you show him is deeply offensive. You have no idea how much work that has been, or would be. And good luck finding a replacement, given your treatment of this man. Why would anyone want such a job if they're going to get heaped with abuse when they use their best judgment? 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. Eliot On 21.09.21 23: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
On Tue, Sep 21, 2021 at 7:54 PM Eliot Lear via tz <tz@iana.org> wrote:
No, and you need to stop throwing a tantrum. This group has existed for decades, and much of the work to maintain both the database and the code was done by Paul. The level of disrespect you show him is deeply offensive. You have no idea how much work that has been, or would be. And good luck finding a replacement, given your treatment of this man. Why would anyone want such a job if they're going to get heaped with abuse when they use their best judgment?
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.
Eliot
I would echo this. It's amazing to me how quickly folks seem to forget how much (thankless) work Paul has put into this project. There has been a lot of back and forth on the original thread between Paul & others, and the fact that there is not currently consensus does not mean that we're in need of either a fork or a new coordinator. The disagreements are part of the dialogue. I get that some folks feel frustrated that this has been an ongoing thing for them for months. Well, now it's in the spotlight. I also agree with what others have said in the meantime -- a revert to 2021a & everyone takes a week to cool off.
Just adding voice having been on this list and its predecessor for a couple decades …
s there consensus on the list that a change is required?
No, I don’t believe so. alan
On Sep 21, 2021, at 14:43, Stephen Colebourne via tz <tz@iana.org> 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
Stephen Colebourne via tz said:
Is there consensus on the list that a change is required?
No. I do not believe that a change is required. (This does not mean uncritically support everything that Paul does.)
Is there a candidate willing to take on the role of TZ Coordinator?
Is there a willing candidate who has shown the technical knowledge and availability to be able to perform the role of TZ Coordinator? Because I'm not seeing one so far. -- 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 2021-09-22 05:42:47 (+0800), 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?
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 -- Philip Paeps Senior Reality Engineer Alternative Enterprises
On 2021-09-22 09:05, Philip Paeps via tz wrote about changing the TZ coordinator:
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
Exactly my opinion. Michael Deckers.
+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 On Wed, Sep 22, 2021, 04:11 Ken Murchison via tz <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
+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
Stephen Colebourne via tz <tz@iana.org> wrote:
Is there consensus on the list that a change is required?
I agree with the suggestion from Robert Masters https://mm.icann.org/pipermail/tz/2021-September/030496.html More broadly, it seems to me as an observer that (as well as the current issue of squashing different zones together) there have been a couple of other contentious decisions by the TZ maintainer in recent years that have caused more upset than necessary: * Dublin winter time: was there enough benefit from being pedantically correct to justify the compatibility problems? * Kyiv: it's clear that the spelling change will need to be made at some point; it's less clear to me what are the benefits of delaying it, or why adding a compatibility Link is undesirable. Another issue that keeps causing friction on the mailing list is the timing of releases. I get the impression that a lot of people would be happier with regular monthly or quarterly releases. Tony. -- f.anthony.n.finch <dot@dotat.at> https://dotat.at/ Dover, Wight, Portland, Plymouth: Variable 2 to 4, becoming west 3 to 5 later. Slight, but slight or moderate in Plymouth. Occasional drizzle later in Plymouth. Moderate or good.
An echo does not make a crowd. I have lurked on this list for years. I am replying from a personal email address because my views are my own. There has been an echo chamber of a relatively few people on the list complaining about the changes. This seems to be far from a consensus. Instead it is a small group that keeps bouncing the same things back and forth without being willing to compromise at all. Either Paul does what you demand or else off with his head! Should they have had more discussion before they were applied? Probably As I understand it, some of the historical data was combined because TZDB was never intended to be a source to map location to timezone. This also removed some names that some might find objectionable, and slimmed down the size of the default data when compiled. There are compile options to still include it. Those compile options need some work to meet the needs of everybody. Instead of throwing a tantrum, how about submitting patches for Paul to review to improve the compile option? If you spent half the effort doing that as you do trying to foment a coup d'état, the compile option might be a solution already. That is what I meant by compromise. On Tue, Sep 21, 2021 at 2:43 PM Stephen Colebourne via tz <tz@iana.org> 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
Just to complete this thread - there is clearly no consensus on this mailing list to change the TZ Coordinator. To aid understanding, under the RFC process that the project is governed by, there are fundamentally two mechanisms applicable when a dispute arises, section 5 (an appeal to the IESG) and section 4 (removal of the Coordinator). Both of these formal avenues have now been tried and failed. The potential options remaining are to fork the project or to solve the issue. For the avoidance of doubt, my preferred option would be to solve the issue. I do note the string support in this thread for the following action: "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" 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? Stephen On Tue, 21 Sept 2021 at 22:42, Stephen Colebourne <scolebourne@joda.org> 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 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.
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
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
To be fair to Paul, a lot of the changes being objected to were reverted <https://github.com/eggert/tz/commit/a82f026448437133ff8ff0e8977c9b46d14c3dcb>. Not all, by any means - 2021b *isn't* the "2021a + Samoa + Jordan" release that many of us were hoping for. But I don't think the situation is quite as stark as this mail implied. It's not like Paul just went ahead with the 2021b that he would no doubt have preferred to release. (To be clear, 2021b isn't the release I'd have preferred either. I'd have really liked to see the urgency taken out of the matter with a "2021a + Samoa + Jordan" release, followed by more consultation. But I don't believe Paul has been completely ignoring users, either.) On Sat, 25 Sept 2021 at 02:11, Jacob Pratt via tz <tz@iana.org> wrote:
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
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. Regardless of Kosovo, it's something I should have fixed long ago - as I wrote earlier I am both busy and forgetful and simply dropped the ball on a task that I had originally intended to finish way back when.
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:05 AM, Clive D.W. Feather wrote:
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
Unfortunately I'd rather not do that with email that was intended to be private. Some of the email was public and you can probably dig it up from the tz archives.
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
It's not just in my head; it's written down in the guidelines (see theory.html). As I wrote to Stephen a few minutes ago, 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.
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.
Paul Eggert said:
Perhaps it would help if you could share with us some of these emails
Unfortunately I'd rather not do that with email that was intended to be private. Some of the email was public and you can probably dig it up from the tz archives.
Could you provide pointers, please, rather than asking us to search without any clues.
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 It's not just in my head; it's written down in the guidelines (see theory.html).
A quote here would be useful.
As I wrote to Stephen a few minutes ago, I thought it was understood that the guidelines are intended to be applied fairly.
The problem is what "fairly" means. Particularly since "equity" doesn't necessarily have the same meaning. This is why explicit definitions from you would help. -- 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: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
On Sep 26, 2021, at 10:39 AM, Paul Eggert via tz <tz@iana.org> wrote:
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".
One thread that finds begins at http://mm.icann.org/pipermail/tz/2013-May/019292.html The Web search also finds non-tzdb-related discussions, such as https://www.icann.org/en/blogs/details/abkhazia-kosovo-south-ossetia-transni... which is ICANN-related in that it relates to giving country codes top-level two-letter domains. To narrow the search to prefer tz mailing list messages, try "Kosovo" "[tz]" site:mm.icann.org which also finds threads beginning at https://mm.icann.org/pipermail/tz/2014-January/020589.html https://mm.icann.org/pipermail/tz/2021-May/030065.html and a few other threads.
participants (28)
-
Alan Perry -
Anthony Hernandez -
Clive D.W. Feather -
D Nathan Cookson -
David Braverman -
Deborah Goldsmith -
Derick Rethans -
Dmitry V. Levin -
dpatte -
Eliot Lear -
Guy Harris -
Jacob Pratt -
Jon Skeet -
Ken Murchison -
Mark Davis ☕️ -
Michael Douglass -
Michael H Deckers -
Paul Eggert -
Paul Goyette -
Philip Paeps -
Robert Masters -
Ronald Tse -
Russ Allbery -
Sanjeev Gupta -
Stephen Colebourne -
Steve Allen -
Tom Lane -
Tony Finch