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.

---------------------------(end of broadcast)---------------------------
TIP 1: 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

Reply via email to