Re: Does PG really lack a time zone for India?

Поиск
Список
Период
Сортировка
От Martijn van Oosterhout
Тема Re: Does PG really lack a time zone for India?
Дата
Msg-id 20060215163304.GB31391@svana.org
обсуждение исходный текст
Ответ на Re: Does PG really lack a time zone for India?  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Does PG really lack a time zone for India?  (Bruce Momjian <pgman@candle.pha.pa.us>)
Список pgsql-general
Comments inline.

On Wed, Feb 15, 2006 at 09:49:57AM -0500, Tom Lane wrote:
> I think defining the problem as "let's get rid of australian_timezones"
> would be a serious mistake.  The basic problem here is that we can't
> have a one-size-fits-all list of timezone abbreviations.  We've
> certainly heard plenty of complaints about IST, and I seem to recall
> some from Brazil, and there are other conflicts noted in the comments
> in the existing list.  So even if there is no one who cares anymore
> about australian_timezones (which I doubt, 'cause that code isn't all
> that old), we still have a problem.

Hmm? The original USE_AUSTRALIAN_RULES timezones were added June
1997[1] for 6.1 and the #define was changed to a GUC in June 2001 [2]
in time for 7.2. The code has been there for ages.

It's funny how it was added though. Someone mentioned the issue in 1997
and said it would be nice to handle, even if it was just via a #define
[3]. Two days later without further discussion the hack was added.

I'm more suggesting some of the totally unused ones (AESST/ACSST) being
removed. I can't find the history of those. They were in the very first
patch to the date/time code from Postgres95 (rev 1.3 of dt.c) but given
they're not known by anyone else I wonder where the list came from.

> > The solution is to allow the timezone portion to be a string like
> > "Australia/Adelaide" and to leave these three letter timezones behind.
>
> While I'd certainly like to see us allow the long forms of timezone
> names within data input, you're living in a dream world if you think
> that people will be willing to type, eg, "Americas/New_York" every time
> where they had been used to entering "EST".  We need to support the
> abbreviations too.

Ah, but the zic library defines EST just fine, so nothing would change
there. You just picked two that are equivalent. Thing is, ACST and
Australia/Adelaide are not equivalent due to daylight savings.

In the timestamp type I created, I simply have a table with all the
timezones in it. If a user wants IST to be something else, they simply
change the table. It's somewhat unusual compared to the way we do most
types, but is there anything inheritly wrong with that approach?

[1] http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/adt/Attic/dt.c.diff?r1=1.25;r2=1.26;f=h
[2]
http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/misc/postgresql.conf.sample.diff?r1=1.11;r2=1.12;f=h
[3] http://archives.postgresql.org/pgsql-hackers/1997-06/msg00400.php

Have a nice day,
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.

Вложения

В списке pgsql-general по дате отправления:

Предыдущее
От: Oisin Glynn
Дата:
Сообщение: Re: Oracle purchases Sleepycat - is this the "other shoe"
Следующее
От: "Nik"
Дата:
Сообщение: Postgres using 100% CPU