Skip site navigation (1) Skip section navigation (2)

Re: Australian timezone configure option

From: Thomas Lockhart <lockhart(at)fourpalms(dot)org>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Chris Dunlop <chris(at)onthe(dot)net(dot)au>, pgsql-patches(at)postgresql(dot)org, Hackers List <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Australian timezone configure option
Date: 2001-06-12 15:04:52
Message-ID: 3B262F94.21C03ECF@fourpalms.org (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
(moved to -hackers list, since this is a *feature change* which should
not just be discussed in -patches)

>>I have decided to make this configurable via postgresql.conf so you
>>don't need separate binaries / configure switch to run in Australia.
>>I will send a patch over for testing.
> We will not be adding this to 7.1.X though you are free to use it in
> that version.  It will appear in 7.2.

Um, er...

I'm not particularly happy about the solution, and would like to not see
it in the main source code without further discussion. Sorry I was out
of town for the extensive two hour discussion on the topic ;)

One could categorize the "Australian problem" as an example of a
localization, and brute-force calls to work around it are a step in the
wrong direction imho. Particularly since Australia contributes fully 25%
of the time zone information in our lookup table, including multiple
synonyms for several time zones. Just as we might want to send a message
to M$ that their SQL hacks are not acceptable, we should send a message
to Australia that playing fast and loose with time zone names should not
be tolerated. Hmm, and while we are at it we should do something about
world hunger and arms race issues. Patches coming soon ;) ;)

OK, those last few sentences were not serious. But, I would like a
solution that starts to address long-term issues in time zone support.

Before hacking the rather carefully evolved static tables let's consider
how to support time localization generally (e.g. language-specific names
for months). In the meantime, a compile-time solution for more easily
setting the "CST" interpretation would seem to be an incremental
improvement for "buildability" (and this has already been submitted).

How about implementing an optional db table-based approach for this
lookup and the other localized info? If it were a compile-time option we
could evaluate the performance impact and allow folks to trade
performance vs features. And perhaps (later, much later. Weeks later...
;) that choice could be a GUC parameter. Comments?

                    - Thomas

In response to

Responses

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2001-06-12 15:18:29
Subject: Re: Australian timezone configure option
Previous:From: Bruce MomjianDate: 2001-06-12 14:59:46
Subject: Re: Fix for tablename in targetlist

pgsql-patches by date

Next:From: Bruce MomjianDate: 2001-06-12 15:14:15
Subject: Re: 7.1 odbc bug & patch
Previous:From: Bruce MomjianDate: 2001-06-12 15:04:21
Subject: Re: 7.1 odbc bug & patch

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group