[tz] Request for change to the tz database

[Brian Inglis]

On 2021-02-08 14:19, John Hawkinson wrote:
> Replies to several recent messages (from Paul, Paul, and Kim) inline:
> 
> Paul Eggert wrote on Mon, 8 Feb 2021 at 15:35:35 EST:
>> Should I ask the tz mailing list moderators (who are not me) to filter out 
>> routine duplicate requests such as this one? At some point the duplicates 
>> start to drown out the more-useful email.
> 
> If we had prepared a standard boilerplate answer that explained the issues 
> and our position on them effectively, I think we could consider doing that. 
> But we have not done so. Saying "go search the list archives" is not very 
> user-friendly, and I don't think it's a reasonable request.
> 
> Further, we have a pending proposal from Paul Eggert on how to address this 
> -- a transition strategy, if you will. I'm not sure how much under
> discussion that really is, or if it is adopted by fiat or default, but
> nonetheless, the state of play today is rather different than it was four
> months ago.

These posts are akin to telling contributors to write in Ukrainian or ...
I would suggest assigning them the action of translating the project and 
contributions into their preferred language and getting it adopted by IANA.

I wish them luck in their endeavours, as it will ensure even less attention by 
English readers to Ukrainian affairs, and congratulate them on their support of 
their opponent's goals.

> Paul Ganssle wrote on Mon,  8 Feb 2021 at 15:45:36 EST:
>> Huge +1 on this. I find the Kiev spam on this list /extremely/ annoying.
> 
> This language and this sentiment is actually offensive.

> The people advocating for Kiev-not-Kiev are not "spamming" the list. They
> are not sending email to the list that is unsolicited (if that even means 
> anything for a mailing list). They are not sending email to the list that is
> commercial in nature. To be "spam," they need to meet both of thoses tests.
> I understand some people like to use the word "spam" to refer to things that
> are simply "annoying," but that's not what it means, and it's not a nice
> thing to do. We should not do it on this list.
We should try to maintain mutual respect and avoid cultural flash points by not 
expressing (too many) non-technical opinions, and try to ignore such comments 
and opinions as we ignore typos.

Using "spam" is modern hyperbolic jargon across communications media for what 
used to be called "line noise"; offense is merely another expression of an 
opinion in the eye of the beholder, the culture they inhabit, and their often 
vivid imaginations: c.f. Mrs. Grundy, Thomas Bowdler, Mary Whitehouse, Anthony 
Comstock, J. Edgar Hoover, Joe McCarthy, Potter Stewart ;^>

> I will say, also, that a recent email about this reminded me of a rather 
> significant hole in the common "[tz identifiers are not supposed to be 
> user-visible, use tzselect() or something instead]" approach. And that is
> that there are quite a few situations where the tz identifier for a location
> is presented (e.g. "What is my system set to?" or databases and websites
> that display information about a locality and present its tz identifier).
> That only reinforces in my mind that, despite our desire to think otherwise,
> tz identifiers are indeed user-visible and pretending otherwise is just
> pretending.

It may be more prevalent in libre projects in English e.g. Mozilla Lightning 
Calendar, and other products with no or little background in alternate locale 
support, nor volunteer time to provide an alternative interface (possibly based 
on tzselect).

> (I'm also struck that there is rarely a direct inquiry into what exact 
> software the user is using that results in being presented with a tz 
> identifier choice. I'd like to hope, if we were truly trying to be helpful,
> that we would ask that question.)
That approach, the suggestion to contact their product support, as those 
internal identifier names should not be visible to users, suggesting they take 
responsibility to provide the product with translations or localizations in 
their preferred language, is probably the best approach to take.

>> It seems like the rule against delving into politics is completely
>> counter-productive because so many e-mails and responses are spent
>> explaining it to new people. Ideally once we realized something is a
>> political hot-button that we're going to get a lot of e-mail about, we'd
>> put it into some automated or semi-automated holding queue where the
>> e-mail is held and the user gets an automated response pointing at the
>> relevant entry in the FAQ.

AFAICT there is no FAQ - pointers? Suggestions? Perhaps someone with sufficient 
interest could break down the theory and how-to documents and present their 
contents in FAQ form to address the most common issues?

> Well, I think it would be reasonable to produce such a FAQ and publish it, 
> but I don't think we should pretermit discussion. And given, above, that the 
> position that would be in that FAQ seem to be changing every few months,
> it's good cause not to automate the response to such inquiries.

> Kim Davies wrote on Mon, 8 Feb 2021 at 15:56:33 EST:
>> If there is general support for the IANA team performing an initial
>> triage for non-subscribers based on the content of their submission,
>> we can work on setting something up. As Paul alludes to at present
>> we are moderating non-subscriber submissions, but only to do a
>> summary check that it is ‘on-topic’, i.e. related to time zone
>> issues.

> Culturally speaking, this is not really how most Internet mailing lists work.
> I do not think that the magnitude of the "problem" supports a solution of
> that nature.
> 
> Indeed, I think the emails to us are useful "check" on our administrative 
> authority. If we were getting 1 inquiry from a new person about Kyiv each
> week, or each day, that would be telling us something. (Something which, I
> would argue, we should listen to).
It's a political campaign, somewhat similar to that against Paul's dropping 
poorly sourced, country specific, pre-1970 info and zones where the record did 
not justify that, and merging a number of zones, because the lack would impact 
those (commercial?) products, uses, and users more than having inaccurate data 
from Shanks et al.

> As it is, we're barely hitting one per month, on the average.

Other lists use milters with standard replies to common non-subscriber posts of 
a certain nature, often pointing to FAQs (see above suggestions).

Perhaps the mods could trigger a standard reply suggesting their product support 
be contacted and informed of the issue (see above suggestions). This could have 
the positive benefit of making products aware of their interface limitations.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]