Re: timezones to own config file

From: Martijn van Oosterhout <kleptog(at)svana(dot)org>
To: Joachim Wieland <joe(at)mcknight(dot)de>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: timezones to own config file
Date: 2006-06-13 12:52:27
Message-ID: 20060613125227.GD19212@svana.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jun 13, 2006 at 02:20:09PM +0200, Joachim Wieland wrote:
> I looked into the timezone specifications and basically extracted a list of
> existing offsets from the zic database.
>
> My proposed format for the timezone files is something like this:

<sip>

Any particular reason this can't be a normal table in pg_catalog which
you can select/update.

> Another problem is that lots of the timezone names that are hardcoded into
> the backend seem to be way outdated or just doubtable, many of them do not
> show up in the zic database.

<snip lots of dodgy timezones>

I've been trying to convince people for a while now that the
appropriate tz string for australia is AEST/ACST/AWST but no-one seems
convinced yet. Hence, I never actually specify timezones and all my
timestamps are inserted as GMT.

IMHO, you should simply setup the table so that it is backward
compatable and let people edit it themselves. You're never going to be
able to convince anyone that people arn't relying on it exactly the way
it is now. The most important thing is to get rid of the
"australian_timezones" hack, everything else is bonus.

> The timezone definition files should be read at server start but should they
> also be read at SIGHUP? If so, should they be read only by the postmaster or
> by all backends?

Good question...

Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Martijn van Oosterhout 2006-06-13 13:00:20 Re: Running a query twice to ensure cached results.
Previous Message Luke Lonergan 2006-06-13 12:46:23 Re: Running a query twice to ensure cached results.