Re: Production systems beware: U.S. Daylight Savings Time comes at a new time this year - Mailing list pgsql-general

From Scott Marlowe
Subject Re: Production systems beware: U.S. Daylight Savings Time comes at a new time this year
Date
Msg-id 1170371504.5451.44.camel@state.g2switchworks.com
Whole thread Raw
In response to Re: Production systems beware: U.S. Daylight Savings Time comes at a new time this year  (Ron Johnson <ron.l.johnson@cox.net>)
List pgsql-general
On Thu, 2007-02-01 at 16:40, Ron Johnson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 02/01/07 15:15, Richard Troy wrote:
> > Hello All,
> >
> > it was recently brought to my attention that last year the U.S. altered
> > the dates when Daylight Savings Time starts and ends. Many if not most
> > computers presume the old change dates and therefore, if left to change
> > automatically, will change at the wrong times. This will be vital for
> > people in the database community who manage applications that need
> > accurate timestamps.
>
> Your distro (or *BSD) should supply updated tz data, no?

Yes, but as of pgsql 8.0 the database does it's own timezone shifting.

However, I wonder.  If it's on a server with the hardware clock tracking
UTC, and a timezone database that might be out of wack, would pgsql
still get the timezones right internally?

Another point.  The timezone databases need to be updated before you
start storing things referencing days during that period.  I.e. if
you've got a scheduling app that's scheduling people today for meetings
on March 12th and the database has an out of date timezone db, then it
will be scheduling them for the wrong times, and when you put the right
tz db on it, it will be an hour off come March 12th.  I think.

pgsql-general by date:

Previous
From: "Demel, Jeff"
Date:
Subject: Re: Subqueries - performance and use question
Next
From: Magnus Hagander
Date:
Subject: Re: I "might" have found a bug on 8.2.1 win32