Re: Simplifying timezone support

On Thu, Feb 20, 2003 at 04:19:21PM -0500, Tom Lane wrote:
> "Ross J. Reedstrom" <reedstrm(at)rice(dot)edu> writes:
> > On Thu, Feb 20, 2003 at 03:21:09PM -0500, Tom Lane wrote:
> >> Provide a portable way of getting libc to tell us whether it likes TZ,
> >> and I'll be glad to fix this.
>
> > Dang that lovely word 'portable'. However, given your proposed change,
> > perhaps the hurdle for portable time handling is now lower: it seems we've
> > not been exposed to as broad a range of broken systems as in the past.
>
> On this particular point my threshold of 'portable' is actually pretty
> low, as long as it's fail-soft. Failure to detect bad TZ on some
> systems would leave them no worse off than before, right?
>
> But I haven't seen *any* published API that directly tells you whether
> tzset liked TZ or not --- AFAICT it's supposed to just silently
> substitute GMT. Which would be okay if "GMT" were the only allowed
> spelling of GMT, but it ain't ...

I've been digging in the date and time code a bit, and now have a proposal
for dealing with SET TIME ZONE 'someunknownstring'. First, we use the
time token table from the time constant parser in utils/adt/datetime.c
to see if we've got a recognized time zone abbreviation. If it is,
we generate a canonical POSIX timezone name for use in setting TZ,
call tzset(), and we're done.

If the time zone came back UNKOWN, we go ahead and see if tzset() can
interpret it. Criteria for failure: if the timezone offset came back 0,
and the reported tzname[0] is the same as the string that we passed in. If
it does, we fire a NOTICE about an unknown spelling of GMT. Note that we
would have already caught all _known_ spellings of GMT in the first step,
so we won't be spamming the DBA with warnings about 'GMT' and 'UTC', etc.

An extension to this would be to use the tzset() trick above directly
in the datetime constant parser, as a fallback after not matching the
table. In that case, we'd probably want to treat the unknown spelling
of GMT as an error, though (as it currently does).

Thoughts? If this seems acceptable, I can implement it this weekend.

Ross