Remove support for timezone "posixrules" file.

The IANA tzcode library has a feature to read a time zone file named
"posixrules" and apply the daylight-savings transition dates and times
therein, when it is given a POSIX-style time zone specification that
lacks an explicit transition rule.  However, there's a problem with
that code: it doesn't work for dates past the Y2038 time_t rollover.
(Effectively, all times beyond that point are treated as standard
time.)  The IANA crew regard this feature as legacy, so their plan is
to remove it not fix it.  The time frame in which that will happen
is unclear, but presumably it'll happen well before 2038.

Moreover, effective with the next IANA data update (probably this
fall), the recommended default will be to not install a "posixrules"
file in the first place.  The time frame in which tzdata packagers
might adopt that suggestion is likewise unclear, but at least some
platforms will probably do it in the next year or so.  While we could
ignore that recommendation so far as PG-supplied tzdata trees are
concerned, builds using --with-system-tzdata will be subject to
whatever the platform's tzdata packager decides to do.

Thus, whether or not we do anything, some increasing fraction of
Postgres users will be exposed to the behavior observed when there
is no "posixrules" file; and if we do nothing, we'll have essentially
no control over the timing of that change.

The best thing to do to ameliorate the uncertainty seems to be to
proactively remove the posixrules-reading feature.  If we do that in
a scheduled release then at least we can release-note the behavioral
change, rather than having users be surprised by it after a routine
tzdata update.

The change in question is fairly minor anyway: to be affected,
you have to be using a POSIX-style timezone spec, it has to not
have an explicit rule, and it has to not be one of the four traditional
continental-USA zone names (EST5EDT, CST6CDT, MST7MDT, or PST8PDT),
as those are special-cased.  Since the default "posixrules" file
provides USA DST rules, the number of people who are likely to find
such a zone spec useful is probably quite small.  Moreover, the
fallback behavior with no explicit rule and no "posixrules" file is to
apply current USA rules, so the only thing that really breaks is the
DST transitions in years before 2007 (and you get the countervailing
fix that transitions after 2038 will be applied).

Now, some installations might have replaced the "posixrules" file,
allowing e.g. EU rules to be applied to a POSIX-style timezone spec.
That won't work anymore.  But it's not exactly clear why this solution
would be preferable to using a regular named zone.  In any case, given
the Y2038 issue, we need to be pushing users to stop depending on this.

Back-patch into v13; it hasn't been released yet, so it seems OK to
change its behavior.  (Personally I think we ought to back-patch
further, but I've been outvoted.)

Discussion: https://postgr.es/m/1390.1562258309@sss.pgh.pa.us
Discussion: https://postgr.es/m/20200621211855.6211-1-eggert@cs.ucla.edu

1 files changed, 11 insertions, 47 deletions

diff --git a/src/timezone/localtime.c b/src/timezone/localtime.c
index 0f65f3c648e..fa3c059038c 100644
--- a/src/timezone/localtime.c
+++ b/src/timezone/localtime.c
@@ -53,14 +53,7 @@ static const char wildabbr[] = WILDABBR;
 static const char gmt[] = "GMT";
 
 /*
- * PG: We cache the result of trying to load the TZDEFRULES zone here.
- * tzdefrules_loaded is 0 if not tried yet, +1 if good, -1 if failed.
- */
-static struct state *tzdefrules_s = NULL;
-static int	tzdefrules_loaded = 0;
-
-/*
- * The DST rules to use if TZ has no rules and we can't load TZDEFRULES.
+ * The DST rules to use if a POSIX TZ string has no rules.
  * Default to US rules as of 2017-05-07.
  * POSIX does not specify the default DST rules;
  * for historical reasons, US rules are a common default.
@@ -986,14 +979,15 @@ tzparse(const char *name, struct state *sp, bool lastditch)
 		return false;
 
 	/*
-	 * The IANA code always tries tzload(TZDEFRULES) here.  We do not want to
-	 * do that; it would be bad news in the lastditch case, where we can't
-	 * assume pg_open_tzfile() is sane yet.  Moreover, the only reason to do
-	 * it unconditionally is to absorb the TZDEFRULES zone's leap second info,
-	 * which we don't want to do anyway.  Without that, we only need to load
-	 * TZDEFRULES if the zone name specifies DST but doesn't incorporate a
-	 * POSIX-style transition date rule, which is not a common case.
+	 * The IANA code always tries to tzload(TZDEFRULES) here.  We do not want
+	 * to do that; it would be bad news in the lastditch case, where we can't
+	 * assume pg_open_tzfile() is sane yet.  Moreover, if we did load it and
+	 * it contains leap-second-dependent info, that would cause problems too.
+	 * Finally, IANA has deprecated the TZDEFRULES feature, so it presumably
+	 * will die at some point.  Desupporting it now seems like good
+	 * future-proofing.
 	 */
+	load_ok = false;
 	sp->goback = sp->goahead = false;	/* simulate failed tzload() */
 	sp->leapcnt = 0;			/* intentionally assume no leap seconds */
 
@@ -1027,38 +1021,8 @@ tzparse(const char *name, struct state *sp, bool lastditch)
 		}
 		else
 			dstoffset = stdoffset - SECSPERHOUR;
-		if (*name == '\0')
-		{
-			/*
-			 * The POSIX zone name does not provide a transition-date rule.
-			 * Here we must load the TZDEFRULES zone, if possible, to serve as
-			 * source data for the transition dates.  Unlike the IANA code, we
-			 * try to cache the data so it's only loaded once.
-			 */
-			if (tzdefrules_loaded == 0)
-			{
-				/* Allocate on first use */
-				if (tzdefrules_s == NULL)
-					tzdefrules_s = (struct state *) malloc(sizeof(struct state));
-				if (tzdefrules_s != NULL)
-				{
-					if (tzload(TZDEFRULES, NULL, tzdefrules_s, false) == 0)
-						tzdefrules_loaded = 1;
-					else
-						tzdefrules_loaded = -1;
-					/* In any case, we ignore leap-second data from the file */
-					tzdefrules_s->leapcnt = 0;
-				}
-			}
-			load_ok = (tzdefrules_loaded > 0);
-			if (load_ok)
-				memcpy(sp, tzdefrules_s, sizeof(struct state));
-			else
-			{
-				/* If we can't load TZDEFRULES, fall back to hard-wired rule */
-				name = TZDEFRULESTRING;
-			}
-		}
+		if (*name == '\0' && !load_ok)
+			name = TZDEFRULESTRING;
 		if (*name == ',' || *name == ';')
 		{
 			struct rule start;