Tom Lane <tgl@sss.pgh.pa.us> writes:
Russ Allbery via tz <tz@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@eyrie.org) <https://www.eyrie.org/~eagle/>