Re: Production systems beware: U.S. Daylight Savings Time comes at a new time this year

Поиск
Список
Период
Сортировка
От Scott Marlowe
Тема Re: Production systems beware: U.S. Daylight Savings Time comes at a new time this year
Дата
Msg-id 1170371504.5451.44.camel@state.g2switchworks.com
обсуждение исходный текст
Ответ на Re: Production systems beware: U.S. Daylight Savings Time comes at a new time this year  (Ron Johnson <ron.l.johnson@cox.net>)
Список 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 по дате отправления:

Предыдущее
От: "Demel, Jeff"
Дата:
Сообщение: Re: Subqueries - performance and use question
Следующее
От: Magnus Hagander
Дата:
Сообщение: Re: I "might" have found a bug on 8.2.1 win32