Support timezone abbreviations that sometimes change.

Up to now, PG has assumed that any given timezone abbreviation (such as
"EDT") represents a constant GMT offset in the usage of any particular
region; we had a way to configure what that offset was, but not for it
to be changeable over time.  But, as with most things horological, this
view of the world is too simplistic: there are numerous regions that have
at one time or another switched to a different GMT offset but kept using
the same timezone abbreviation.  Almost the entire Russian Federation did
that a few years ago, and later this month they're going to do it again.
And there are similar examples all over the world.

To cope with this, invent the notion of a "dynamic timezone abbreviation",
which is one that is referenced to a particular underlying timezone
(as defined in the IANA timezone database) and means whatever it currently
means in that zone.  For zones that use or have used daylight-savings time,
the standard and DST abbreviations continue to have the property that you
can specify standard or DST time and get that time offset whether or not
DST was theoretically in effect at the time.  However, the abbreviations
mean what they meant at the time in question (or most recently before that
time) rather than being absolutely fixed.

The standard abbreviation-list files have been changed to use this behavior
for abbreviations that have actually varied in meaning since 1970.  The
old simple-numeric definitions are kept for abbreviations that have not
changed, since they are a bit faster to resolve.

While this is clearly a new feature, it seems necessary to back-patch it
into all active branches, because otherwise use of Russian zone
abbreviations is going to become even more problematic than it already was.
This change supersedes the changes in commit 513d06d et al to modify the
fixed meanings of the Russian abbreviations; since we've not shipped that
yet, this will avoid an undesirably incompatible (not to mention incorrect)
change in behavior for timestamps between 2011 and 2014.

This patch makes some cosmetic changes in ecpglib to keep its usage of
datetime lookup tables as similar as possible to the backend code, but
doesn't do anything about the increasingly obsolete set of timezone
abbreviation definitions that are hard-wired into ecpglib.  Whatever we
do about that will likely not be appropriate material for back-patching.
Also, a potential free() of a garbage pointer after an out-of-memory
failure in ecpglib has been fixed.

This patch also fixes pre-existing bugs in DetermineTimeZoneOffset() that
caused it to produce unexpected results near a timezone transition, if
both the "before" and "after" states are marked as standard time.  We'd
only ever thought about or tested transitions between standard and DST
time, but that's not what's happening when a zone simply redefines their
base GMT offset.

In passing, update the SGML documentation to refer to the Olson/zoneinfo/
zic timezone database as the "IANA" database, since it's now being
maintained under the auspices of IANA.

Author: tglsfdc

contrib/btree_gist/btree_ts.c

@@ -200,27 +200,11 @@ tstz_dist(PG_FUNCTION_ARGS)
  **************************************************/
 
 
-static Timestamp
+static inline Timestamp
 tstz_to_ts_gmt(TimestampTz ts)
 {
-	Timestamp	gmt;
-	int			val,
-				tz;
-
-	gmt = ts;
-	DecodeSpecial(0, "gmt", &val);
-
-	if (ts < DT_NOEND && ts > DT_NOBEGIN)
-	{
-		tz = val * 60;
-
-#ifdef HAVE_INT64_TIMESTAMP
-		gmt -= (tz * INT64CONST(1000000));
-#else
-		gmt -= tz;
-#endif
-	}
-	return gmt;
+	/* No timezone correction is needed, since GMT is offset 0 by definition */
+	return (Timestamp) ts;
 }
 
 

doc/src/sgml/config.sgml

@@ -6003,9 +6003,9 @@ SET XML OPTION { DOCUMENT | CONTENT };
         Sets the collection of time zone abbreviations that will be accepted
         by the server for datetime input.  The default is <literal>'Default'</>,
         which is a collection that works in most of the world; there are
-        also <literal>'Australia'</literal> and <literal>'India'</literal>, and other collections can be defined
-        for a particular installation.  See <xref
-        linkend="datetime-appendix"> for more information.
+        also <literal>'Australia'</literal> and <literal>'India'</literal>,
+        and other collections can be defined for a particular installation.
+        See <xref linkend="datetime-config-files"> for more information.
        </para>
       </listitem>
      </varlistentry>

doc/src/sgml/datatype.sgml

@@ -2325,7 +2325,7 @@ January 8 04:05:06 1999 PST
     but continue to be prone to arbitrary changes, particularly with
     respect to daylight-savings rules.
     <productname>PostgreSQL</productname> uses the widely-used
-    <literal>zoneinfo</> (Olson) time zone database for information about
+    IANA (Olson) time zone database for information about
     historical time zone rules.  For times in the future, the assumption
     is that the latest known rules for a given time zone will
     continue to be observed indefinitely far into the future.
@@ -2390,8 +2390,8 @@ January 8 04:05:06 1999 PST
         The recognized time zone names are listed in the
         <literal>pg_timezone_names</literal> view (see <xref
         linkend="view-pg-timezone-names">).
-        <productname>PostgreSQL</productname> uses the widely-used
-        <literal>zoneinfo</> time zone data for this purpose, so the same
+        <productname>PostgreSQL</productname> uses the widely-used IANA
+        time zone data for this purpose, so the same time zone
         names are also recognized by much other software.
        </para>
       </listitem>
@@ -2427,7 +2427,7 @@ January 8 04:05:06 1999 PST
         When a daylight-savings zone abbreviation is present,
         it is assumed to be used
         according to the same daylight-savings transition rules used in the
-        <literal>zoneinfo</> time zone database's <filename>posixrules</> entry.
+        IANA time zone database's <filename>posixrules</> entry.
         In a standard <productname>PostgreSQL</productname> installation,
         <filename>posixrules</> is the same as <literal>US/Eastern</>, so
         that POSIX-style time zone specifications follow USA daylight-savings
@@ -2438,9 +2438,25 @@ January 8 04:05:06 1999 PST
      </itemizedlist>
 
      In short, this is the difference between abbreviations
-     and full names: abbreviations always represent a fixed offset from
-     UTC, whereas most of the full names imply a local daylight-savings time
-     rule, and so have two possible UTC offsets.
+     and full names: abbreviations represent a specific offset from UTC,
+     whereas many of the full names imply a local daylight-savings time
+     rule, and so have two possible UTC offsets.  As an example,
+     <literal>2014-06-04 12:00 America/New_York</> represents noon local
+     time in New York, which for this particular date was Eastern Daylight
+     Time (UTC-4).  So <literal>2014-06-04 12:00 EDT</> specifies that
+     same time instant.  But <literal>2014-06-04 12:00 EST</> specifies
+     noon Eastern Standard Time (UTC-5), regardless of whether daylight
+     savings was nominally in effect on that date.
+    </para>
+
+    <para>
+     To complicate matters, some jurisdictions have used the same timezone
+     abbreviation to mean different UTC offsets at different times; for
+     example, in Moscow <literal>MSK</> has meant UTC+3 in some years and
+     UTC+4 in others.  <application>PostgreSQL</> interprets such
+     abbreviations according to whatever they meant (or had most recently
+     meant) on the specified date; but, as with the <literal>EST</> example
+     above, this is not necessarily the same as local civil time on that date.
     </para>
 
     <para>
@@ -2457,13 +2473,14 @@ January 8 04:05:06 1999 PST
     </para>
 
     <para>
-     In all cases, timezone names are recognized case-insensitively.
-     (This is a change from <productname>PostgreSQL</productname> versions
-     prior to 8.2, which were case-sensitive in some contexts but not others.)
+     In all cases, timezone names and abbreviations are recognized
+     case-insensitively.  (This is a change from <productname>PostgreSQL</>
+     versions prior to 8.2, which were case-sensitive in some contexts but
+     not others.)
     </para>
 
     <para>
-     Neither full names nor abbreviations are hard-wired into the server;
+     Neither timezone names nor abbreviations are hard-wired into the server;
      they are obtained from configuration files stored under
      <filename>.../share/timezone/</> and <filename>.../share/timezonesets/</>
      of the installation directory

doc/src/sgml/datetime.sgml

@@ -374,22 +374,27 @@
     these formats:
 
 <synopsis>
-<replaceable>time_zone_name</replaceable> <replaceable>offset</replaceable>
-<replaceable>time_zone_name</replaceable> <replaceable>offset</replaceable> D
+<replaceable>zone_abbreviation</replaceable> <replaceable>offset</replaceable>
+<replaceable>zone_abbreviation</replaceable> <replaceable>offset</replaceable> D
+<replaceable>zone_abbreviation</replaceable> <replaceable>time_zone_name</replaceable>
 @INCLUDE <replaceable>file_name</replaceable>
 @OVERRIDE
 </synopsis>
    </para>
 
    <para>
-    A <replaceable>time_zone_name</replaceable> is just the abbreviation
-    being defined.  The <replaceable>offset</replaceable> is the zone's
+    A <replaceable>zone_abbreviation</replaceable> is just the abbreviation
+    being defined.  The <replaceable>offset</replaceable> is the equivalent
     offset in seconds from UTC, positive being east from Greenwich and
     negative being west.  For example, -18000 would be five hours west
     of Greenwich, or North American east coast standard time.  <literal>D</>
-    indicates that the zone name represents local daylight-savings time
-    rather than standard time. Since all known time zone offsets are on
-    15 minute boundaries, the number of seconds has to be a multiple of 900.
+    indicates that the zone name represents local daylight-savings time rather
+    than standard time.  Alternatively, a <replaceable>time_zone_name</> can
+    be given, in which case that time zone definition is consulted, and the
+    abbreviation's meaning in that zone is used.  This alternative is
+    recommended only for abbreviations whose meaning has historically varied,
+    as looking up the meaning is noticeably more expensive than just using
+    a fixed integer value.
    </para>
 
    <para>
@@ -400,24 +405,24 @@
 
    <para>
     The <literal>@OVERRIDE</> syntax indicates that subsequent entries in the
-    file can override previous entries (i.e., entries obtained from included
-    files).  Without this, conflicting definitions of the same timezone
-    abbreviation are considered an error.
+    file can override previous entries (typically, entries obtained from
+    included files).  Without this, conflicting definitions of the same
+    timezone abbreviation are considered an error.
    </para>
 
    <para>
     In an unmodified installation, the file <filename>Default</> contains
     all the non-conflicting time zone abbreviations for most of the world.
     Additional files <filename>Australia</> and <filename>India</> are
     provided for those regions: these files first include the
-    <literal>Default</> file and then add or modify timezones as needed.
+    <literal>Default</> file and then add or modify abbreviations as needed.
    </para>
 
    <para>
     For reference purposes, a standard installation also contains files
     <filename>Africa.txt</>, <filename>America.txt</>, etc, containing
     information about every time zone abbreviation known to be in use
-    according to the <literal>zoneinfo</> timezone database.  The zone name
+    according to the IANA timezone database.  The zone name
     definitions found in these files can be copied and pasted into a custom
     configuration file as needed.  Note that these files cannot be directly
     referenced as <varname>timezone_abbreviations</> settings, because of
@@ -426,9 +431,9 @@
 
    <note>
     <para>
-     If an error occurs while reading the time zone data sets, no new value is
-     applied but the old set is kept. If the error occurs while starting the
-     database, startup fails.
+     If an error occurs while reading the time zone abbreviation set, no new
+     value is applied and the old set is kept. If the error occurs while
+     starting the database, startup fails.
     </para>
    </note>
 

doc/src/sgml/installation.sgml

@@ -1108,7 +1108,7 @@ su - postgres
         <para>
          <productname>PostgreSQL</> includes its own time zone database,
          which it requires for date and time operations.  This time zone
-         database is in fact compatible with the <quote>zoneinfo</> time zone
+         database is in fact compatible with the IANA time zone
          database provided by many operating systems such as FreeBSD,
          Linux, and Solaris, so it would be redundant to install it again.
          When this option is used, the system-supplied time zone database

src/backend/utils/adt/date.c

@@ -2695,24 +2695,39 @@ timetz_zone(PG_FUNCTION_ARGS)
 	pg_tz	   *tzp;
 
 	/*
-	 * Look up the requested timezone.  First we look in the date token table
-	 * (to handle cases like "EST"), and if that fails, we look in the
-	 * timezone database (to handle cases like "America/New_York").  (This
-	 * matches the order in which timestamp input checks the cases; it's
-	 * important because the timezone database unwisely uses a few zone names
-	 * that are identical to offset abbreviations.)
+	 * Look up the requested timezone.  First we look in the timezone
+	 * abbreviation table (to handle cases like "EST"), and if that fails, we
+	 * look in the timezone database (to handle cases like
+	 * "America/New_York").  (This matches the order in which timestamp input
+	 * checks the cases; it's important because the timezone database unwisely
+	 * uses a few zone names that are identical to offset abbreviations.)
 	 */
 	text_to_cstring_buffer(zone, tzname, sizeof(tzname));
+
+	/* DecodeTimezoneAbbrev requires lowercase input */
 	lowzone = downcase_truncate_identifier(tzname,
 										   strlen(tzname),
 										   false);
 
-	type = DecodeSpecial(0, lowzone, &val);
+	type = DecodeTimezoneAbbrev(0, lowzone, &val, &tzp);
 
 	if (type == TZ || type == DTZ)
-		tz = val * MINS_PER_HOUR;
+	{
+		/* fixed-offset abbreviation */
+		tz = -val;
+	}
+	else if (type == DYNTZ)
+	{
+		/* dynamic-offset abbreviation, resolve using current time */
+		pg_time_t	now = (pg_time_t) time(NULL);
+		struct pg_tm *tm;
+
+		tm = pg_localtime(&now, tzp);
+		tz = DetermineTimeZoneAbbrevOffset(tm, tzname, tzp);
+	}
 	else
 	{
+		/* try it as a full zone name */
 		tzp = pg_tzset(tzname);
 		if (tzp)
 		{