Re: timezones to own config file

Поиск
Список
Период
Сортировка
От Martijn van Oosterhout
Тема Re: timezones to own config file
Дата
Msg-id 20060613125227.GD19212@svana.org
обсуждение исходный текст
Ответ на timezones to own config file  (Joachim Wieland <joe@mcknight.de>)
Ответы Re: timezones to own config file  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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@svana.org>   http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.

В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Luke Lonergan"
Дата:
Сообщение: Re: Running a query twice to ensure cached results.
Следующее
От: Martijn van Oosterhout
Дата:
Сообщение: Re: Running a query twice to ensure cached results.