Re: Does PG really lack a time zone for India? - Mailing list pgsql-general

From Martijn van Oosterhout
Subject Re: Does PG really lack a time zone for India?
Date
Msg-id 20060215163304.GB31391@svana.org
Whole thread Raw
In response to Re: Does PG really lack a time zone for India?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Does PG really lack a time zone for India?  (Bruce Momjian <pgman@candle.pha.pa.us>)
List 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.

Attachment

pgsql-general by date:

Previous
From: Oisin Glynn
Date:
Subject: Re: Oracle purchases Sleepycat - is this the "other shoe"
Next
From: "Nik"
Date:
Subject: Postgres using 100% CPU