Skip site navigation (1) Skip section navigation (2)

Re: Server Time Setting

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Lane Van Ingen <lvaningen(at)ESNCC(dot)com>,"Obe, Regina DND\\MIS" <robe(dot)dnd(at)cityofboston(dot)gov>,pgsql-hackers-win32(at)postgresql(dot)org
Subject: Re: Server Time Setting
Date: 2005-09-15 16:37:24
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers-win32
Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> Tom Lane wrote:
>> Should pgtz.c try to detect this situation and handle it by mapping to a
>> non-DST-aware internal timezone?

> I think this is a simple case of misconfiguration and I suspect fiddling 
> with it would just open up the possibility of more errors.

Maybe.  The other thing that's worrisome here is the likelihood that
people would fiddle with the setting after starting Postgres; which
is a scenario we really can't do much about, but AFAICS it would have
the same effect that now() would deviate from what the system clock
is showing.

I'm not sure it's worth the trouble to try to handle the "box not
checked" case fully --- as you say, anyone who's handling DST by
manually adjusting the system clock twice a year is going to lose
anyway.  But if we can detect that setting easily, maybe we could just
insist that it match the behavior we're expecting (ie, fail to find a
matching timezone and complain about it)?  It seems to me better that
there be an obvious failure immediately than that the system appear to
work only to start giving wrong answers after the next time change.

			regards, tom lane

In response to

pgsql-hackers-win32 by date

Next:From: Andrew DunstanDate: 2005-09-15 16:59:54
Subject: Re: Server Time Setting
Previous:From: Lane Van IngenDate: 2005-09-15 16:20:17
Subject: Re: Server Time Setting

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group