From: | Steve Crawford <scrawford(at)pinpointresearch(dot)com> |
---|---|
To: | DM <dm(dot)aeqa(at)gmail(dot)com> |
Cc: | pgsql-admin(at)postgresql(dot)org |
Subject: | Re: Urgent PST time changing tonight |
Date: | 2009-03-09 19:14:07 |
Message-ID: | 49B56A7F.6040004@pinpointresearch.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Scott Marlowe | 2009-03-09 19:18:33 | Re: Urgent PST time changing tonight |
Previous Message | Scott Marlowe | 2009-03-08 09:29:08 | Re: Urgent PST time changing tonight |