On Fri, Feb 21, 2003 at 06:15:31PM -0500, Tom Lane wrote:
> "Ross J. Reedstrom" <reedstrm@rice.edu> 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
