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@xxxxxxxxxxxxx> wrote:
Don Seiler <don@xxxxxxxxx> 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
www.seiler.us
