Re: FATAL: invalid value for parameter "TimeZone" after upgrade from 9.2 to 9.6

I agree that it isn't valid, and I get that same error when I try to set
the timezone to CST after I connect.

The difference though is when the client sets that timezone when
connecting, that's when the error is listed as FATAL and the connections
fail in 9.6 (and also 9.3 according to the previous thread), where as the
connections didn't fail in 9.2 and earlier. That's the behavior change I'm
looking to account for.

Don.

On Fri, Nov 17, 2017 at 9:25 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Don Seiler <don(at)seiler(dot)us> writes:
> > My issue is more or less similar to
> > http://www.postgresql-archive.org/Upgrading-from-PG-8-3-3-
> to-9-3-4-FATAL-invalid-value-for-parameter-quot-TimeZone-
> quot-quot-PST-quot-td5805665.html
>
> > However what I'm looking to answer is why this wasn't fatal in 9.2?
>
> It was. I don't think PG has ever accepted just "PST" (or "CDT") as a
> timezone name. There's no such entry in the IANA tz database, and it's
> not a legal POSIX zone specification --- you'd need at least "PST8" for
> it to go through that code path. I tried it just now on 7.4.30, which is
> the oldest version I have on this machine (about 2 years older than 9.2.0)
> and it failed as expected:
>
> regression=# set timezone = 'PST';
> ERROR: unrecognized time zone name: "PST"
>
> Now, it's barely conceivable that you strong-armed 9.2 into accepting
> it by making a file or symlink named "PST" in the timezone database
> directory of the old installation ... but otherwise, I'm quite certain
> it would not have taken it.
>
> regards, tom lane
>

--
Don Seiler
www.seiler.us