Add regression test coverage for non-default timezone abbreviation sets.
authorTom Lane <[email protected]>
Mon, 5 Sep 2016 00:02:16 +0000 (20:02 -0400)
committerTom Lane <[email protected]>
Mon, 5 Sep 2016 00:02:16 +0000 (20:02 -0400)
After further reflection about the mess cleaned up in commit 39b691f25,
I decided the main bit of test coverage that was still missing was to
check that the non-default abbreviation-set files we supply are usable.
Add that.

Back-patch to supported branches, just because it seems like a good
idea to keep this all in sync.

src/test/regress/expected/timestamptz.out
src/test/regress/sql/timestamptz.sql
src/timezone/README

index 71d56ff9d70a7eb8cc70220f7385e9bca86a9323..4032f0ef397066d3a774f788e916451ac9cab502 100644 (file)
@@ -2365,3 +2365,18 @@ select count(distinct utc_offset) >= 24 as ok from pg_timezone_abbrevs;
  t
 (1 row)
 
+-- Let's check the non-default timezone abbreviation sets, too
+set timezone_abbreviations = 'Australia';
+select count(distinct utc_offset) >= 24 as ok from pg_timezone_abbrevs;
+ ok 
+----
+ t
+(1 row)
+
+set timezone_abbreviations = 'India';
+select count(distinct utc_offset) >= 24 as ok from pg_timezone_abbrevs;
+ ok 
+----
+ t
+(1 row)
+
index 42fbba8b5d457886a42a59ec6b06622a1eba1b1f..30c794a5d10859bd7137f24d0ad5894176f5a495 100644 (file)
@@ -390,3 +390,8 @@ SELECT '2007-12-09 07:30:00 UTC'::timestamptz AT TIME ZONE 'VET';
 --
 select count(distinct utc_offset) >= 24 as ok from pg_timezone_names;
 select count(distinct utc_offset) >= 24 as ok from pg_timezone_abbrevs;
+-- Let's check the non-default timezone abbreviation sets, too
+set timezone_abbreviations = 'Australia';
+select count(distinct utc_offset) >= 24 as ok from pg_timezone_abbrevs;
+set timezone_abbreviations = 'India';
+select count(distinct utc_offset) >= 24 as ok from pg_timezone_abbrevs;
index 1df4ce1f69a1c2d26d8ceba471efd966b575c254..f2f80c7176a8f8afa9b01919e5154a2573603549 100644 (file)
@@ -34,6 +34,11 @@ in the same commit.  Usually, if a known abbreviation has changed meaning,
 the appropriate fix is to make it refer to a long-form zone name instead
 of a fixed GMT offset.
 
+The core regression test suite does some simple validation of the zone
+data and abbreviations data (notably by checking that the pg_timezone_names
+and pg_timezone_abbrevs views don't throw errors).  It's worth running it
+as a cross-check on proposed updates.
+
 When there has been a new release of Windows (probably including Service
 Packs), the list of matching timezones need to be updated. Run the
 script in src/tools/win32tzlist.pl on a Windows machine running this new