Negative DST, or, should we delay using tzdata 2018e update?

Earlier this week I pushed tzdata 2018d into our tree, expecting that
that would be the current IANA timezone data for next week's releases.
Well, I was wrong; today they pushed out a new version:

https://mm.icann.org/pipermail/tz-announce/2018-May/000050.html

on account of North Korea deciding to change their time zone with a
week's notice.

Ordinarily I'd just absorb 2018e and be done with it. But I am feeling
hesitant about this update, because it also incorporates this change:

Bring back the negative-DST changes of 2018a, except be more
compatible with data parsers that do not support negative DST.
Also, this now affects historical time stamps in Namibia and the
former Czechoslovakia, not just Ireland. The main format now uses
negative DST to model time stamps in Europe/Dublin (from 1971 on),
Europe/Prague (1946/7), and Africa/Windhoek (1994/2017). This
does not affect UT offsets, only time zone abbreviations and the
tm_isdst flag. Also, this does not affect rearguard or vanguard
formats; effectively the main format now uses vanguard instead of
rearguard format. Data parsers that do not support negative DST
can still use data from the rearguard tarball described below.

As the announcement hints, this "negative DST" business was sufficiently
controversial that the initial attempt to push it was rescinded, on the
grounds that negative DST offsets might break people's software, and
some lead time was required to deal with that.

Basically, the point here is that it seems that in Ireland, legal
"standard time" is what they use in summer, and in winter they use
"daylight savings" time that is one hour behind standard time, rather
than one hour ahead as is usually meant by "daylight savings". Up to
now the IANA database has just ignored the fact that "IST" is legally
"Irish Standard Time" not "Irish Summer Time", but now they want to
represent it properly.

From our point of view, the question is whether any applications are
likely to get confused if the "is_dst" column shown in pg_timezone_names
and pg_timezone_abbrevs is turned on for offsets that are one hour behind
their zone's "regular" time instead of one hour ahead. I do not think
anything inside PG will get confused (though I could be wrong about that).
Application-level problems of this sort seem possible but not very likely.

We have a couple of alternatives:

1. Bull ahead and push tzdata 2018e into our tree, and ship that with
Monday's releases. I am scared of this choice, because there is
basically no time remaining to detect or recover from any problems.

2. Delay applying 2018e until after next week's releases, so that we have
three months for any problems to get noticed. (Also, 2018e could go out
with v11 betas, so that we can expect there would actually be some field
testing of it before it'd be released in back branches.)

3. As the announcement mentions, there's a "rear guard" version of
the tzdata files in which the negative-DST changes haven't been made.
Perhaps we could use that version for awhile, maybe only in the back
branches. But eventually we'd have to change --- it's pretty clear that
the IANA crew isn't going to maintain this "rear guard" format forever ---
and it's not clear that postponing the pain would make anything better.

An important consideration here is that for a very large fraction of
our users, our choices here won't affect things in the least: any package
that uses --with-system-tzdata is going to be subject to the platform's
decisions about which tzdata to use and when to push it, not ours.

We can be pretty certain that bleeding-edge-loving platforms (e.g. Gentoo)
will push negative-DST-using tzdata soon. Therefore, our code has to be
prepared to work with that even if we don't ship it. This leads me to
think that we'd best incorporate 2018e into HEAD and ship it in 11beta,
regardless of what we do for the back branches.

I don't particularly want to get into a situation where we're shipping
different tzdata in v11+ than in older branches; that'd be a maintenance
nightmare. So I'm not enamored of the variants of option 3 that would
have us doing that. But the variant in which we ship rear-guard data
in all branches seems like it's just postponing a problem that we
can't postpone forever.

On balance I'm leaning towards option #2, ie go with the new data but
wait till just after the minor releases. Thoughts?

regards, tom lane