[tz] An alternate framing of timezone maintenance

[Russ Allbery]

Tom Lane <tgl at sss.pgh.pa.us> writes:
> Russ Allbery via tz <tz at iana.org> writes:

>> I completely agree that this thread is about the long-term direction
>> and an attempt to provide a way of reframing the problem so that
>> various parties don't feel backed into a corner with no path forward
>> other than a fork.  None of this discussion addresses the immediate
>> concern of what is in the 2021b release.

> So after thinking about this for awhile, I don't see how adding a layer
> of indirection would help us as far as the contentious questions go.
> That's because the contentious questions are about what view of the data
> will be seen by the average end user using a default installation of
> tzdb.  We can't abdicate making choices about that, and we shouldn't
> want to, because if every platform vendor starts making their own
> choices about it we'll have chaos.

I agree with almost all of that except the critical place where I think it
might help: separating the data from the naming means that people who
primarily want to work on the data and find the naming frustrating and
political *can* abdicate making choices about that.  Specifically, the
naming and the data can be maintained by *different people*.

My outsider perspective is that a large source of the conflict here is
different goals.  From Paul's previous statements, I think it's clear that
he wants his work to be as apolitical as possible and is uncomfortable
with the places where the tzdata database necessarily makes political
decisions involving naming.  Separating the naming from the data creates a
set of data that one can work on apolitically.

I completely agree with you that someone still has to maintain the naming
and make those political decisions, but that work is much less *technical*
and much more obviously political.  Perhaps, with a level of indirection,
the people who do not want to do that political work (or are not
well-equipped to do it, which I would argue this mailing list probably is
not) will see a path clear to delegate that work to another group that is
willing to take it on.  Then everyone is working on things that are near
and dear to their heart without being forced to consider things that they
find unpleasant.

In other words, this isn't a *technical* fix (although it requires a
technical component).  It's a *social* approach, which to me felt like the
piece that was missing in previous discussions.

> To take an example, I think people would agree that best practice right
> now for letting a user select their time zone is to provide a world map
> that can be clicked on.  (macOS does it that way for instance.)  So the
> user clicks somewhere within Norway ... what next?  Should the machine
> now pop up a dialog box saying "I see you are in Norway.  Would you prefer
> probably-accurate pre-1970 data for Norway, or certainly-wrong pre-1970
> data for Norway?"

Obviously not; obviously the author of the time zone selection tool should
be opinionated about that choice and make a choice for the user.  And
obviously those opinions should be pooled and hashed out somewhere.

The key point is that somewhere *doesn't need to be here*.  This is less
obvious for something like Norway and becomes more obvious if the user
clicks on Hebron or Crimea or Xinjiang.  The tz project already does not
take a position on the mapping of geographical coordinates to time zones
and leaves that to other projects.

Obviously there is input that needs to flow in both directions.  For
instance, clearly indicating the quality and believed accuracy of a given
data set would be useful.  But my point is that so much of this conflict
currently is between folks who are trying to remove politics from the work
and folks who care very deeply about the outcome of those political
decisions (or about stability decisions which, while not directly about
politics, have significant impact on the political layer and very little
impact on the data collection layer).

We can't stop doing both parts of that work, but we *can* separate them so
that everyone gets some distance and can retreat to the part of the work
that they care about the most without impacting the other side of it.

> If tzdb were to say "You can't write America/New_York any more, you have
> to write TZ5828", the universal response would be "Up with this nonsense
> I shall not put".

No, this is definitely not what I'm saying.  It's obvious that we cannot
discard the current naming layer, and indeed a partial attempt to do that
is exactly what set off the current disagreement.

-- 
Russ Allbery (eagle at eyrie.org)             <https://www.eyrie.org/~eagle/>