Re: Comment on timezone and interval types

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Michael Glaesemann <grzm(at)myrealbox(dot)com>
Cc: Martijn van Oosterhout <kleptog(at)svana(dot)org>, Postgresql General <pgsql-general(at)postgresql(dot)org>
Subject: Re: Comment on timezone and interval types
Date: 2004-10-27 15:13:13
Message-ID: 20370.1098889993@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Michael Glaesemann <grzm(at)myrealbox(dot)com> writes:
> On Oct 27, 2004, at 6:00 PM, Martijn van Oosterhout wrote:
>> How can there be a "canonical list of known timezones" if every
>> operating system has it's own list. Maybe you can provide a base list,
>> but you have to allow for people to make their own.

> My understanding is that with the addition of the zic time zone data to
> the PostgreSQL server, there's no longer any need to rely on OS time
> zone data.

Correct, but it is still the case that different installations will need
to have slightly different timezone lists. Consider for example the
australian_timezones kluge we have now, and consider that there are
several known cases of zone name conflicts that are not covered by
australian_timezones (the one I remember at the moment is IST which both
the Israelis and the Indians use; but I think there are some others).
I think the most reasonable way to solve this will be to invent a
configuration file that lets people list the zone abbreviations they
want to use and the corresponding UTC offsets. We will need a mapping
method that can cope with changes in such a file.

But having said that, I concur with Martijn that there is no problem,
because the OIDs (or whatever numeric ID we use) are inside the database
and will never be visible outside it. There is no more portability risk
here than there is in using platform-native byte order in integers.

regards, tom lane

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2004-10-27 15:27:35 Re: [NOVICE] ABRUPT CLOSURE OF POSTGRESQL SOCKET
Previous Message Jon Uhal 2004-10-27 14:48:57 Foreign Key Non-Null Problem in 8.0