From: | Scott Marlowe <smarlowe(at)g2switchworks(dot)com> |
---|---|
To: | Ron Johnson <ron(dot)l(dot)johnson(at)cox(dot)net> |
Cc: | pgsql general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Production systems beware: U.S. Daylight Savings Time comes at a new time this year |
Date: | 2007-02-01 23:11:44 |
Message-ID: | 1170371504.5451.44.camel@state.g2switchworks.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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.
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2007-02-01 23:11:56 | Re: I "might" have found a bug on 8.2.1 win32 |
Previous Message | Demel, Jeff | 2007-02-01 23:06:49 | Re: Subqueries - performance and use question |