On Fri, Feb 21, 2003 at 05:45:53PM -0600, Ross J. Reedstrom wrote:
> 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.
O.K., I've run the test: of the 1108 files in my zoneinfo database,
only 11 have matching filenames to the canonical name returned after
setting TZ. Of those 11, 4 are some version of GMT (GMT, UCT, UTC,
WET), of which, one is in fact missing from our table - UCT. At minimum,
I'll add that.
Every other validly formatted TZ variable that returns GMT should be
caught be the datetktbl check.
I'll play with it this weekend, see how hard it is to make it work.
Ross