Message-ID: <49B56A7F.6040004@pinpointresearch.com>
Date: Mon, 09 Mar 2009 12:14:07 -0700
From: Steve Crawford <scrawford@pinpointresearch.com>
User-Agent: Thunderbird 2.0.0.19 (X11/20090105)
MIME-Version: 1.0
To: DM <dm.aeqa@gmail.com>
CC: pgsql-admin@postgresql.org
Subject: Re: Urgent PST time changing tonight
References: <eae6a62a0903072358o15b1cefdt661627cefc05b3b0@mail.gmail.com>
In-Reply-To: <eae6a62a0903072358o15b1cefdt661627cefc05b3b0@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

DM wrote:
> Hi All,
>
> PST time changing tonight, I am not sure if this is going to affect 
> the database....
IF you are up-to-date on your TZ files the database itself should be 
fine. But external processing is another matter - especially if you have 
processes that assume conventions from previous PG versions. For example:

PG 7.4 (one day = 24 hours):
select now();

              now
-------------------------------
 2009-03-09 12:05:42.533139-07

 select now()-'2 days'::interval;
           ?column?
-------------------------------
 2009-03-07 11:05:43.963526-08


But in 8.3 (day interval is DST aware):
select now();

              now
-------------------------------
 2009-03-09 12:04:21.813654-07

select now()-'2 days'::interval;
           ?column?
-------------------------------
 2009-03-07 12:04:47.693384-08

That's just in the database itself and without cross-country processing 
(i.e.: if you have somewhat synchronized processes that assume that New 
York is 3 hours ahead of San Francisco you can have problems if you 
don't consider that New York changed to DST 3 hours ahead of San Francisco).

Then there are the scripts that calculate dates externally for feeding 
into your database-backed processes (for fun, try "-d yesterday" and "-d 
tomorrow" in most versions of the "date" command in the vicinity of DST 
changes).

Cheers,
Steve