Fix timestamptz regression test to still work with latest IANA zone data.
authorTom Lane <tgl@sss.pgh.pa.us>
Thu, 9 Mar 2017 22:20:11 +0000 (17:20 -0500)
committerTom Lane <tgl@sss.pgh.pa.us>
Thu, 9 Mar 2017 22:20:11 +0000 (17:20 -0500)
commitd8ec6b9c8c265c2f29b1c0e0e4205895baaa326d
tree9696cacf6d5b420b5e94d6a89cd3aae044353265
parente0a6ed8a2525b10bf86285f3d6e56b3672457cda
Fix timestamptz regression test to still work with latest IANA zone data.

The IANA timezone crew continues to chip away at their project of removing
timezone abbreviations that have no real-world currency from their
database.  The tzdata2017a update removes all such abbreviations for
South American zones, as well as much of the Pacific.  This breaks some
test cases in timestamptz.sql that were expecting America/Santiago and
America/Caracas to have non-numeric abbreviations.

The test cases involving America/Santiago seem to have selected that
zone more or less at random, so just replace it with America/New_York,
which is of similar longitude.  The cases involving America/Caracas are
harder since they were chosen to test a time-varying zone abbreviation
around a point where it changed meaning in the backwards direction.
Fortunately, Europe/Moscow has a similar case in 2014, and the MSK/MSD
abbreviations are well enough attested that IANA seems unlikely to
decide to remove them from the database in future.

With these changes, this regression test should pass when using any IANA
zone database from 2015 or later.  One could wish that there were a few
years more daylight on how out-of-date your zone database can be ... but
really the --with-system-tzdata option is only meant for use on platforms
where the zone database is kept up-to-date pretty faithfully, so I do not
think this is a big objection.

Discussion: https://postgr.es/m/6749.1489087470@sss.pgh.pa.us
src/test/regress/expected/timestamptz.out
src/test/regress/sql/timestamptz.sql