On Thu, Feb 20, 2003 at 03:21:09PM -0500, Tom Lane wrote: > "Ross J. Reedstrom" <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
