"Ross J. Reedstrom" <[EMAIL PROTECTED]> writes:
> 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.
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.
> 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 ...
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
