> 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 onene 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 majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

On Thu, Sep 07, 2006 at 05:29:04AM +1000, Naz Gassiep wrote:
> 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.

Ugh. It'd be an argument if people actually used SAT as a timezone.
They don't, it's ACST.

Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFE/zmoIB7bNG8LQkwRAvTwAJ9mJxPX4fH/Bf0AAnp4l5Rw91wskwCfZUjp
BHu0THPi1PY77j1EBo4UAPM=
=kf8O
-----END PGP SIGNATURE-----