Awhile back, "Ross J. Reedstrom" <reedstrm@rice.edu> wrote:
> Second solution - try tzset() first, and apply the following heuristic
> to see if it took:
> tzname[0]==$TZ and tzname[1]=="" and timezone=0 and daylight=0
I finally went back to look at this issue, and soon realized that the
above test is in fact glibc-specific. Other implementations of tzset()
may act differently. On HPUX, tzset() appears to adopt the system-wide
setting (from /etc/zoneinfo/localtime) if TZ contains a garbage string.
And yet, that's a better fallback behavior than adopting GMT.
I have applied a patch that just checks for tzname[1] not empty or
timezone != 0; either one means that tzset was able to interpret TZ as a
non-GMT zone (or that it gave up and reverted to a non-GMT default zone,
which we can't distinguish anyway). Failing that, it looks to see if
the string is known as a GMT equivalent to DecodeTimezone. If not, it
complains.
I did not include Ross' idea of accepting other zone names known to
DecodeTimezone as if they were a numeric-offset value. We could still
do that if people like it, but it seemed a bigger change in behavior
than just trying to check that tzset() worked.
I also added code that detects and rejects a leap-second-aware timezone
definition, since we've now seen a couple different reports of systems
where such zones seem to be installed by default, leading to breakage
of our date/time arithmetic.
regards, tom lane