On Fri, Feb 21, 2003 at 06:15:31PM -0500, Tom Lane wrote: > "Ross J. Reedstrom" <[EMAIL PROTECTED]> writes: <snip> > > I'm worried about cases like "Africa/Benin" for places that just happen > to be on the prime meridian, but don't call their time GMT or UTC. > Looking at a globe, it also seems possible that there are places an hour > west of Greenwich, for which this could fail during daylight-savings > season.
Well, that'll either get caught by the existing table (we've got six different spellings of GMT, currently) or by the 'string in != string out' case - the zoneinfo format requires a 3 or more character abbreviation for the time zone. For every case I'v looked at in my zoneinfo directory, it's either 3 or 4 uppercase characters, and _never_ matches the filename path string used to set it. I'll do an exhaustive test after dinner. > > > 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). > > I think tzset() is probably much too slow to consider calling on every > pass through timestamptz_in ... It wouldn't happen on every call - only with funky timezone representations. We could NOTICE use of tzset(), as well, to alert the DBA about something fishy, if you'd like. Ross ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org
