On Thu, Feb 20, 2003 at 03:21:09PM -0500, Tom Lane wrote:
> "Ross J. Reedstrom" <reedstrm@rice.edu> writes:
> > question about pgsql's time zone parsers. It appears there's at least
> > two, since SET TIME ZONE accepts strings like 'US/Eastern', while general
> > timestamp parsing doesn't:
>
> The TIME ZONE string is fed to libc (via TZ environment variable); the
> other cases are not.
>
> > SET TIME ZONE will silently accept any string at all, and fall back to
> > providing GMT when a timestamptz is requested.
>
> 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.
I'll look at it. but no promises.
> Ultimately we should probably get rid of our dependence on the libc
> time routines altogether ... but I have no intention of opening that
> can of worms right now. See past discussions in the archives.
Agreed. I see we're inheriting the actually misleading case from the
OS/libc, as well:
wallace$ unset TZ
wallace$ date
Thu Feb 20 15:00:04 CST 2003
wallace$ export TZ=US/Central
wallace$ date
Thu Feb 20 15:00:16 CST 2003
wallace$ export TZ=US/Zanzibar
wallace$ date
Thu Feb 20 21:00:33 US/Zanzibar 2003
wallace$ export TZ=CST
wallace$ date
Thu Feb 20 21:00:42 CST 2003
wallace$
Ross