Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
> On my RH-5.2 box, "JST" is not in /usr/share/zoneinfo. A non-existant
> TZ evaluates to be GMT, but the system reports the string you gave
> it!! I don't recall ever running across this before.
Ugh. RedHat's not the only one: on my HPUX 10 box,
$ date
Thu Jan 20 11:13:26 EST 2000
$ TZ=GMT date
Thu Jan 20 16:13:30 GMT 2000
$ TZ=ZZZ date
Thu Jan 20 16:13:35 ZZZ 2000
$ TZ=foo date
Thu Jan 20 16:13:53 foo 2000
This may be a fairly widespread bug^H^H^Hbizarre behavior.
> I'm not sure how one would check to verify that the timezone you set
> is actually a valid timezone. I'd hate to restrict it to the list of
> timezones Postgres knows about when parsing input (since that is a
> subset of the possibilities), though that is one solution...
Well, we could solve a smaller problem: keep a list of the timezone
names we think are equivalent to GMT. Then, if we see a zero TZ offset
for any name not in the list, emit some sort of warning notice. Bit of
a kluge though.
I am not sure that this relates to Tatsuo's complaint, though.
His issue was:
> test=> select '1998-09-23 12:05:10 HST'::datetime;
> ------------------------------
> Thu Sep 24 07:05:10 1998 JST
> test=> show timezone;
> NOTICE: Time zone is unknown
If Postgres doesn't know the timezone, why is it displaying "JST" in
decoded datetimes?
Another odd thing is that I'd have expected the displayed time to be
GMT if the system doesn't know the timezone --- but the time being
shown here is 9 hours ahead of JST, not 9 hours behind... perhaps
something somewhere *does* know the local zone, but is applying the
correction backwards?
regards, tom lane