Re: Urgent PST time changing tonight - Mailing list pgsql-admin

From Scott Marlowe
Subject Re: Urgent PST time changing tonight
Date
Msg-id dcc563d10903080129l2b835c00o446ba65272dfade@mail.gmail.com
Whole thread Raw
In response to Re: Urgent PST time changing tonight  (DM <dm.aeqa@gmail.com>)
List pgsql-admin
On Sun, Mar 8, 2009 at 1:53 AM, DM <dm.aeqa@gmail.com> wrote:
> Thanks Scott,
> If i leave the system as is without any upgrade, what issues i might see any
> idea?
> do postgres has any patches for the changes. i dont want to install a new
> databae at this time, i have 1 hr to go..
> Thanks

Assuming that some update to DST got missed, then you're output will
all be off by an hour from what they should be when retrieved for that
timezone that has it wrong.  I remember there being something a while
back about moving one of the timezones a few days.  You can always
create and retrieve timestamps ahead of time (i.e. a timestamp in the
future) and see what offset it has to see if it's coming out right.

The real problem gets created when timestamps are inserted now for the
future.  If there's a rule that we fall back 1 week off from what your
TZ data says, and you insert it today, with the old TZ on your
machine, it will be inserted as the wrong time, with the wrong offset
to get it to GMT.  This cropped up a year ago with some change our
windows machines at work didn't have, and all the schedules created by
those machines were off by an hour until the newly created events
(created with the right timezone offset values) started showing up and
we got past the window where time actually did match up again.

So, leaving these to stew can be a real problem, if you're not keeping
up with the tz info.

pgsql-admin by date:

Previous
From: DM
Date:
Subject: Re: Urgent PST time changing tonight
Next
From: Steve Crawford
Date:
Subject: Re: Urgent PST time changing tonight