Re: Timezone List
От | Naz Gassiep |
---|---|
Тема | Re: Timezone List |
Дата | |
Msg-id | 44FF2180.5040202@mira.net обсуждение исходный текст |
Ответ на | Re: Timezone List (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Timezone List
(Tom Lane <tgl@sss.pgh.pa.us>)
Re: Timezone List (Martijn van Oosterhout <kleptog@svana.org>) |
Список | pgsql-hackers |
> 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.
В списке pgsql-hackers по дате отправления: