<div dir="ltr"><div dir="ltr"><br></div><div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 8 Feb 2021 at 18:24, Brian Inglis <<a href="mailto:Brian.Inglis@systematicsw.ab.ca">Brian.Inglis@systematicsw.ab.ca</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> (I'm also struck that there is rarely a direct inquiry into what exact <br>
> software the user is using that results in being presented with a tz <br>
> identifier choice. I'd like to hope, if we were truly trying to be helpful,<br>
> that we would ask that question.)<br>
That approach, the suggestion to contact their product support, as those <br>
internal identifier names should not be visible to users, suggesting they take <br>
responsibility to provide the product with translations or localizations in <br>
their preferred language, is probably the best approach to take.</blockquote><div><br></div><div>We have used that approach for quite some time.  One shortcoming, though, is that I get the sense that a lot of vendors react with a WONTFIX or "that's an upstream problem", trying to pass the buck back at us.</div><div><br></div><div>And I get it.  Developing a really *good* UI for timezone selection is hard, especially if you're doing it from scratch and it's not the core of your product.  Indeed, we've seen a few threads saying, in effect, "we've reached out to our vendor, but they say they can't change the IDs because they get them straight from tz".  Yes, there's a line or two in our theory file that says pretty emphatically NOT to do that, but perhaps some clearer "best practices" guidelines for downstream users of this project could stand to be fleshed out.  Maybe tzselect should spawn a cousin that operates a bit closer to our favorite exemplars in macOS and Ubuntu.  Regardless, fixing where that sense of (shared) responsibility should be placed is largely a social problem that won't easily or quickly go away, but we should continue to try to lead by example.</div><div><br></div><div>Even so, as software development in general continues to become more prevalent, more and more people are being exposed to these identifiers in their natural environment anyway, which must also be considered.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> Indeed, I think the emails to us are useful "check" on our administrative <br>
> authority. If we were getting 1 inquiry from a new person about Kyiv each<br>
> week, or each day, that would be telling us something. (Something which, I<br>
> would argue, we should listen to).<br>
It's a political campaign, somewhat similar to that against Paul's dropping <br>
poorly sourced, country specific, pre-1970 info and zones where the record did <br>
not justify that, and merging a number of zones, because the lack would impact <br>
those (commercial?) products, uses, and users more than having inaccurate data <br>
from Shanks et al.<br></blockquote><div><br></div><div>In some ways, the raw number and frequency of similar requests matters: it is a signal of interest.  In others, it does not: if everyone is repeating the same talking points, it doesn't move discussion forward and only means that we're hearing the "squeakiest" wheels, not necessarily what will best serve the userbase as a whole.  To the extent that the raw counts do matter, employing moderation could still, in theory, result in a periodic summarization without subjecting the list to needless repetition, e.g., "we got N such requests this month, a few of them made the following points which seem novels."  That would be just as useful a signal to us as N long, winding, (and heated!) email threads if they fail to offer much that's new.</div><div><br></div><div>On the technical side, Paul made his proposal in November, and a major goal of that proposal was to *actually discuss its merits and flaws* prior to its potential implementation.  It seems, from limited commentary then and a bit more commentary now, that the interim (forward-compatibility) approach is somewhat less favored.  I'm inclined to agree that this need not be treated as a special case that introduces more complexity to the project.  But it's important that that discussion actually happens before any change is implemented.  I can't guess whether, upon making such a change, we wouldn't swiftly see a similar campaign to "change it back!"  And then what?  So, please… do speak up if you have anything new to add on the technical side.</div><div><br></div><div>Whatever approach we take — in this case as in any other — needs to be supported by the data.  Whether that needs to be in absolute terms or in terms of a clear trend is of course subject to interpretation, and so, though it seems to me that folks both on and off this list are indeed generally moving toward supporting this change, moderating and using a boilerplate response in the meantime can help provide our volunteers with the space and breathing room to conduct the necessary work to back it up with its due diligence.  And then, hopefully, we can instead be discussing whether/how that data makes this clearer.</div><div></div></div></div><div dir="ltr"><br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">--<br>Tim Parenti</div></div></div></div>