Re: Timezone List

> Actually, what that view gives you is timezone offset abbreviations, not
> the full zone names that you could use with SET TIME ZONE. It strikes
> me that we should have a view for that as well. We could use code
> similar to scan_available_timezones() to generate the view output.
>
> It's somewhat urgent to address this now, because pg_timezonenames is
> sitting on the obvious name for such a view, and once we release 8.2
> we won't be able to change it. On reflection I think the existing view
> is wrongly named --- perhaps it should be pg_timezoneabbrevs? Or
> more readably, perhaps pg_timezone_abbrevs, with pg_timezone_names for
> the other view.
>
> regards, tom lane
>
I agree with having two views, and I also think that the name as it is,
is not right. I agree with pg_timezone_abbrevs and pg_timezone_names or
similar.

On a related note, there is not a one:one relationship between
abbreviations and zone names, some abbreviations are used by two zones
(forex "EST", "CST" and others are used in Australia and the Americas)
and currently it is a server configuration directive
(australian_timezones) to assume Australian or American zones in the
case of ambiguity.

I don't know about anyone else, but the whole australian_timezones thing
seems like an ugly hackaround to me. I do not have a proposed solution
to this, but I see a non-trivial risk of an application being
re-deployed on a server where the admin forgets to change this directive
resulting in all kinds of fun and games. Forgive me if this is an
already-discussed issue.

I am also rather baffled at the way "SAT" is changed from being
interpreted as a day of the week in one mode, and a timezone in another.
This seems an awful incongruity of behavior, and "SAT" should be
interpreted as a timezone in both modes. If it must be done, switching
of this behavior doesn't fit in with the purpose of the
australian_timezones directive and should be made the subject of a
different directive (e.g., sat_is_timezone(boolean) or something
similar). SAT should, IMHO, always be considered a timezone and use of
the "SAT" string by DB programmers should be just another case for care
as with any other SQL keyword.