[tz] Request for change to the tz database

Tim Parenti tim at timtimeonline.com
Tue Feb 9 00:18:19 UTC 2021

On Mon, 8 Feb 2021 at 18:24, Brian Inglis <Brian.Inglis at systematicsw.ab.ca>

> > (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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20210208/946f63ce/attachment.htm>

More information about the tz mailing list