tzdata2017a breaks timestamptz regression test

I typically build with --with-system-tzdata, which means that any time
Red Hat sees fit to push out a new copy of the tzdata package, that's
what I'm testing against.  This morning they updated to tzdata2017a,
and I'm seeing the attached test failures.

The reason for this is that the IANA crew have really moved forward
aggressively on their project to remove invented zone abbreviations.
As stated at
http://mm.icann.org/pipermail/tz-announce/2017-February/000045.html
they've removed text abbreviations for pretty much all of South
America, which is what's breaking these cases.

For the cases involving the America/Santiago zone, I'm a bit inclined
to just switch that to America/New_York, which seems much less likely
to get fooled with by IANA.  But I'm wondering if Alvaro had a specific
reason for using the Santiago zone in those test cases.

The diffs involving VET (America/Caracas) are more problematic: we're
intentionally trying to test a time-varying zone abbreviation, so we can't
just switch to a stable zone.  As far as the lines 2395..2437 hunk goes,
we could perhaps make that segment of the test print in ISO datestyle
instead of Postgres datestyle, which would force the zone to be printed in
numeric form not as an abbreviation.  That's slightly annoying, but it
doesn't really compromise what that part of the test is trying to test.
However, the very last hunk indicates that VET no longer functions as a
time-varying zone abbreviation at all, because it doesn't match any
abbreviation recorded for America/Caracas in the IANA database, so we fall
back to treating it as a simple synonym for America/Caracas (cf commit
39b691f25).  So that's now failing altogether to test what it means to.

What I propose we do about that is replace the America/Caracas test cases
with Europe/Moscow tests, moving the dates as needed to match DST
transitions from when Moscow was observing DST (pre 2011).  The comments
in the IANA files indicate that they believe the MSK/MSD abbreviations
have or had real-world usage, so they probably won't replace them with
numeric offsets.  We can hope, anyway.

			regards, tom lane