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. 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?" The idea is laughable --- nobody's going to take the second choice if presented with the option. Lower-level APIs for selecting time zone, such as setting a TZ environment variable or filling in /etc/localtime, typically involve time zone names these days. For instance on my Linux machine I've got $ ls -l /etc/localtime lrwxrwxrwx. 1 root root 38 May 30 2020 /etc/localtime -> ../usr/share/zoneinfo/America/New_York You can quibble about whether that's the most ideal representation, but it's what we've arrived at, and I think there's not much chance of changing 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". There would instantly spring up a cottage industry making APIs to map intelligible identifiers to TZ IDs, and the best outcome we could hope for is that all those APIs chose to just duplicate the old zone names. If every system decided to invent its own names for zones, again we've got chaos that serves nobody. So really the responsibility for choosing those names has to stay with tzdb. In short, I think that opaque IDs that are hidden within tzdb won't add anything, while exposing them as external identifiers is just a non-starter. That's probably why the previous discussions of the idea haven't gone anywhere. regards, tom lane