[tz] An alternate framing of timezone maintenance

[Tom Lane]

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.

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