Re: Australian timezone configure option

I hate the Australian configure option because it means that you can't use the
pre-built postgres
that comes with RedHat or whatever. Surely the correct solution is to have a
config file somewhere
that gets read on startup? That way us Australians don't have to be the only
ones in the world
that need a custom built postgres.

I'd just like to ask, will making USE_AUSTRALIAN_RULES as a GUC option mean
the regression tests work?

And DST changes will work fine too (although I think that's more Linux system
related).

etc.

As in, I'm in favour of a GUC option, but if it breaks regressions tests or
other stuff, then I'd have second thoughts.

Regards and best wishes,

Justin Clift

On Tuesday 12 June 2001 15:00, chris(dot)bitmead(at)health(dot)gov(dot)au wrote:
> I hate the Australian configure option because it means that you can't use
> the pre-built postgres
> that comes with RedHat or whatever. Surely the correct solution is to have
> a config file somewhere
> that gets read on startup? That way us Australians don't have to be the
> only ones in the world
> that need a custom built postgres.
>
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://www.postgresql.org/search.mpl

My patch allows the regression tests to pass too.

> I'd just like to ask, will making USE_AUSTRALIAN_RULES as a GUC option mean
> the regression tests work?
>
> And DST changes will work fine too (although I think that's more Linux system
> related).
>
> etc.
>
> As in, I'm in favour of a GUC option, but if it breaks regressions tests or
> other stuff, then I'd have second thoughts.
>
> Regards and best wishes,
>
> Justin Clift
>
> On Tuesday 12 June 2001 15:00, chris(dot)bitmead(at)health(dot)gov(dot)au wrote:
> > I hate the Australian configure option because it means that you can't use
> > the pre-built postgres
> > that comes with RedHat or whatever. Surely the correct solution is to have
> > a config file somewhere
> > that gets read on startup? That way us Australians don't have to be the
> > only ones in the world
> > that need a custom built postgres.
> >
> >
> >
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 6: Have you searched our list archives?
> >
> > http://www.postgresql.org/search.mpl
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

> Surely the correct solution is to have a config file somewhere
> that gets read on startup? That way us Australians don't have to be the only
> ones in the world that need a custom built postgres.

I will point out that "you Australians", and, well, "us 'mericans", are
the only countries without the sense to choose unique conventions for
time zone names.

It sounds like having a second lookup table for the Australian rules is
a possibility, and this sounds fairly reasonable to me. Btw, is there an
Australian convention for referring to North American time zones for
those zones with naming conflicts?

- Thomas

On Thu, Jun 14, 2001 at 12:23:22AM +0000, Thomas Lockhart wrote:
> > Surely the correct solution is to have a config file somewhere
> > that gets read on startup? That way us Australians don't have to be the only
> > ones in the world that need a custom built postgres.
>
> I will point out that "you Australians", and, well, "us 'mericans", are
> the only countries without the sense to choose unique conventions for
> time zone names.
>
> It sounds like having a second lookup table for the Australian rules is
> a possibility, and this sounds fairly reasonable to me. Btw, is there an
> Australian convention for referring to North American time zones for
> those zones with naming conflicts?

For years I've been on the TZ list, the announcement list for a
community-maintained database of time zones. One point they have
firmly established is that there is no reasonable hope of making
anything like a standard system of time zone name abbreviations work.
Legislators and dictators compete for arbitrariness in their time
zone manipulations.

Even if you assign, for your own use, an abbreviation to a particular
administrative region, you still need a history of legislation for that
region to know what any particular time record (particularly and April
or September) really means.

The "best practice" for annotating times is to tag them with the numeric
offset from UTC at the time the sample is formed. If the time sample is
the present time, you don't have to know very much make or use it. If
it's in the past, you have to know the legislative history of the place
to form a proper time record, but not to use it. If the time is in the
future, you cannot know what offset will be in popular use at that time,
but at least you can be precise about what actual time you really mean,
even if you can't be sure about what the wall clock says. (Actual wall
clock times are not reliably predictable, a fact that occasionally makes
things tough on airline passengers.)

Things are a little more stable in some places (e.g. in Europe it is
improving) but worldwide all is chaos.

Assigning some country's current abbreviations at compile time is madness.

Nathan Myers
ncm(at)zembu(dot)com