Re: UCT (Re: pgsql: Update time zone data files to tzdata release 2019a.)

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> I'm kind of unsure what to think about this whole debate
> substantively. If Andrew is correct that zone.tab or zone1970.tab is a
> list of time zone names to be preferred over alternatives, then it
> seems like we ought to prefer them.

It's not really clear to me that the IANA folk intend those files to
be read as a list of preferred zone names. If they do, what are we
to make of the fact that no variant of "UTC" appears in them?

> He remarks that we are preferring
> "deprecated backward-compatibility aliases" and to the extent that
> this is true, it seems like a bad thing. We can't claim to be
> altogether here apolitical, because when those deprecated
> backward-compatibility names are altogether removed, we are going to
> remove them and they're going to stop working. If we know which ones
> are likely to suffer that fate eventually, we ought to stop spitting
> them out. It's no more political to de-prefer them when upstream does
> than it is to remove them with the upstream does.

I think that predicting what IANA will do in the future is a fool's
errand. Our contract is to select some one of the aliases that the
tzdb database presents, not to guess about whether it might present
a different set in the future. (Also note that a lot of the observed
variation here has to do with whether individual platforms choose to
install backward-compatibility zone names. I think the odds that
IANA proper will remove those links are near zero; TTBOMK they
never have removed one yet.)

More generally, my unhappiness about Andrew's proposal is:

1. It's solving a problem that just about nobody cares about, as
evidenced by the very tiny number of complaints we've had to date.
As long as the "timezone" setting has the correct external behavior
(UTC offset, DST rules, and abbreviations), very few people notice
it at all. With the addition of the code to resolve /etc/localtime
when it's a symlink, the population of people who might care has
taken a further huge drop.

2. Changing this behavior might create more problems than it solves.
In particular, it seemed to me that a lot of the complaints in the
UCT/UTC kerfuffle were less about "UCT is a silly name for my zone"
than about "this change broke my regression test that expected
timezone to be set to X in this environment". Rearranging the tiebreak
rules is just going to make different sets of such people unhappy.
(Admittedly, the symlink-lookup addition has already created some
risk of this ilk. Maybe we should wait for that to be in the field
for more than a week before we judge whether further hacking is
advisable.)

3. The proposal has technical issues, in particular I'm not nearly
as sanguine as Andrew is about whether we can rely on zone[1970].tab
to be available.

So I'm very unexcited about writing a bunch of new code or opening
ourselves to politically-driven complaints in order to change this.
It seems like a net loss almost independently of the details.

regards, tom lane