Re: More tzdb fun: POSIXRULES is being deprecated upstream

Last year I wrote:
> Paul Eggert, in https://mm.icann.org/pipermail/tz/2019-June/028172.html:
>> zic’s -p option was intended as a transition from historical
>> System V code that treated TZ="XXXnYYY" as meaning US
>> daylight-saving rules in a time zone n hours west of UT,
>> with XXX abbreviating standard time and YYY abbreviating DST.
>> zic -p allows the tzdata installer to specify (say)
>> Europe/Brussels's rules instead of US rules. This behavior
>> is not well documented and often fails in practice; for example it
>> does not work with current glibc for contemporary timestamps, and
>> it does not work in tzdb itself for timestamps after 2037.
>> So, document it as being obsolete, with the intent that it
>> will be removed in a future version. This change does not
>> affect behavior of the default installation.

Well, we ignored this for a year, but it's about to become unavoidable:
http://mm.icann.org/pipermail/tz/2020-June/029093.html
IANA upstream is changing things so that by default there will not be
any "posixrules" file in the tz database.

That wouldn't directly affect our builds, since we don't use their
Makefile anyway. But it will affect installations that use
--with-system-tzdata, which I believe is most vendor-packaged
Postgres installations.

It's possible that most or even all tzdata packagers will ignore
the change and continue to ship a posixrules file, for backwards
compatibility's sake. But I doubt we should bet that way.
glibc-based distros, in particular, would have little motivation to
do so. We should expect that, starting probably this fall, there
will be installations with no posixrules file.

The minimum thing that we have to do, I'd say, is to change the
documentation to explain what happens if there's no posixrules file.
However, in view of the fact that the posixrules feature doesn't work
past 2037 and isn't going to be fixed, maybe we should just nuke it
now rather than waiting for our hand to be forced. I'm not sure that
I've ever heard of anyone replacing the posixrules file anyway.
(The fallback case is actually better in that it works for dates past
2037; it's worse only in that you can't configure it.)

I would definitely be in favor of "nuke it now" with respect to HEAD.
It's a bit more debatable for the back branches. However, all branches
are going to be equally exposed to updated system tzdata trees, so
we've typically felt that changes in the tz-related code should be
back-patched.

Thoughts?

regards, tom lane