Re: Australian timezone configure option - Mailing list pgsql-patches

From Thomas Lockhart
Subject Re: Australian timezone configure option
Date
Msg-id 3B262F94.21C03ECF@fourpalms.org
Whole thread Raw
In response to Re: Australian timezone configure option  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-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

pgsql-patches by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Patch to include PAM support...
Next
From: Chris Dunlop
Date:
Subject: Re: Australian timezone configure option