From: | ncm(at)zembu(dot)com (Nathan Myers) |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Australian timezone configure option |
Date: | 2001-06-14 01:05:42 |
Message-ID: | 20010613180542.N18121@store.zembu.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Joe Conway | 2001-06-14 01:19:52 | Re: Re: [PATCHES] Fw: Isn't pg_statistic a security hole - Solution Proposal |
Previous Message | Bruce Momjian | 2001-06-14 00:58:24 | Re: Australian timezone configure option |
From | Date | Subject | |
---|---|---|---|
Next Message | Joe Conway | 2001-06-14 01:19:52 | Re: Re: [PATCHES] Fw: Isn't pg_statistic a security hole - Solution Proposal |
Previous Message | Tom Lane | 2001-06-14 01:03:11 | Re: High memory usage |