Re: timezones to own config file

Поиск
Список
Период
Сортировка
От Joachim Wieland
Тема Re: timezones to own config file
Дата
Msg-id 20060530193256.GB2448@mcknight.de
обсуждение исходный текст
Ответ на Re: timezones to own config file  (Martijn van Oosterhout <kleptog@svana.org>)
Список pgsql-hackers
Martijn,

On Fri, May 26, 2006 at 03:03:15PM +0200, Martijn van Oosterhout wrote:
> > I think you may be thinking of yet a separate TODO item, which is to
> > be able to use the zic timezone names in timestamptz input, viz
> >     '2006-05-24 21:11 Americas/New_York'::timestamptz
> > But names like 'IST' or 'CDT' are not zic timezone names, they just
> > represent specific offsets from UTC.

> Well, the zic database does contain information about the
> abbreviations, so we would be able to build a list of them.

That's what i've done already  :-)

> I think the right solution is probably fix the above first (allow full zic
> timezones in timestamps) and then setup the CST/CEST/etc as a list of
> aliases users can customise...

Why do you think that full zic timezone in timestamps should be done first?
For me, both features are independent, but maybe I've missed something.

As I understand it, the time zone abbreviations are not aliases for full zic
names but only for offsets.

So if you set "Region/City" as the timezone, the offset depends on the year
(because countries have changed their timezones in the past) and whether or
not DST is or was active at that time.

On the other hand, a timezone abbreviation only means "GMT + x hours" and
nothing more. The relation between both now is that a "Region/City" timezone
changes its timezone abbreviation over the years (to reflect changes to
timezones done in the past) and during the year (to reflect changes due to
daylight saving time). And this is actually what the zic database is all
about.


Joachim


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

Предыдущее
От: "Marc G. Fournier"
Дата:
Сообщение: Re: anoncvs still slow
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [GENERAL] 8.1.4 - problem with PITR - .backup.done / backup.ready version of the same file at the same time.