[tz] Request for change to the tz database

[John Hawkinson]

I want to reiterate two points, that seem like they are getting lost, although, Tim, your message touched on them:

1) These emails from list outsiders have been quite effective in moving forward the on-list discussion about Kyiv. I don't think Paul's November proposal would have happened if we didn't have them, and to me it appears there is more and more concensus now about how to move forward, and again it is triggered by these outside emails. Shutting them down because they are effective would be troubling.

2) As I raised earlier today, the validity of a tz identifer is about more than just the user interface for timezone selection, which is essentially a "solved problem," even if not every software package has solved it. That UI doesn't do anything for the people who ask, "What zone is my computer set to?" or those who ask, such as through the Google Timezone API https://developers.google.com/maps/documentation/timezone/overview, "What is the TZ identifier for this location or for this long/lat pair?"

(That question is the logical outgrowth of the first screenshot that Yaroslav Bilko posted in his second email to the list on Friday.
I'm not sure where that screenshot came from. I hope we're not so inured to these emails about Kyiv-not-Kiev that we cannot stop to read each one and look at the new points that are raised).

--
jhawk at alum.mit.edu
John Hawkinson


Tim Parenti <tim at timtimeonline.com> wrote on Mon,  8 Feb 2021
at 19:18:19 EST in <CAFpi07wT3hXdmbhmygHj+_Mw1cbUir4YWf=NWh7gG24CkP_Cvg at mail.gmail.com>:

> On Mon, 8 Feb 2021 at 18:24, Brian Inglis <Brian.Inglis at systematicsw.ab.ca>
> wrote:
> 
> > > (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.
> 
> 
> 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.
> 
> 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.
> 
> 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.
> 
> > 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.
> >
> 
> 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.
> 
> 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.
> 
> 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.
> 
> --
> Tim Parenti