Received: from localhost (unknown [200.46.208.211]) by mail.postgresql.org (Postfix) with ESMTP id 5FE6A635925 for ; Tue, 10 Mar 2009 02:13:10 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.208.211]) (amavisd-maia, port 10024) with ESMTP id 19058-02-9 for ; Tue, 10 Mar 2009 02:13:02 -0300 (ADT) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.168]) by mail.postgresql.org (Postfix) with ESMTP id 4AF3C635048 for ; Tue, 10 Mar 2009 02:11:38 -0300 (ADT) Received: by wf-out-1314.google.com with SMTP id 23so2181213wfg.28 for ; Mon, 09 Mar 2009 22:11:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=cqUOTa7hpPD14MsMPSJpG1jiEnLEjs4EVt1bkLd3M6w=; b=fWJFLqcI/lQOFjZ+1NSszNoyRnCjQW2dYaG+Lp809lPiFXNJxeID6cAJppMXHW5X3l /d1+QJzpeZ/uQDzJ3V8B5gC2ZA/Vvz6LqvFP+EdCYYVsMsmCaVY1zh2rVVVZovJjsKld 7DEjmiE5GOXJuRipDZ6ZIkYs+DUViL3VcFhfE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=q1l30FQdJTFitNwNF/5u7BD3jR9lm1ia3ApDZfv9XBRA8vtXjFGu4X1cJEkAK8gH6+ onbsBGw9RomHuhnKgYHtubXgjug0JFzw8NRTiCXYobGlz32QkEaVsKem3mcMpfWAMaRj 1EiNne1IqectImJQqUw1/wvq5dkEL5RrkBCfM= MIME-Version: 1.0 Received: by 10.143.163.12 with SMTP id q12mr2511941wfo.224.1236661897871; Mon, 09 Mar 2009 22:11:37 -0700 (PDT) In-Reply-To: <49B56A7F.6040004@pinpointresearch.com> References: <49B56A7F.6040004@pinpointresearch.com> Date: Mon, 9 Mar 2009 22:11:37 -0700 Message-ID: Subject: Re: Urgent PST time changing tonight From: DM To: Steve Crawford Cc: pgsql-admin@postgresql.org Content-Type: multipart/alternative; boundary=0016368e25cc2143900464bcc970 X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.001 tagged_above=0 required=5 tests=HTML_MESSAGE=0.001 X-Spam-Level: X-Archive-Number: 200903/115 X-Sequence-Number: 31615 --0016368e25cc2143900464bcc970 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Thanks Steve for sharing this info. Thanks Deepak On Mon, Mar 9, 2009 at 12:14 PM, Steve Crawford < scrawford@pinpointresearch.com> wrote: > 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 > > --0016368e25cc2143900464bcc970 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks Steve for sharing this info.

Thanks
Dee= pak

On Mon, Mar 9, 2009 at 12:14 PM, Stev= e Crawford <scrawford@pinpointresearch.com> wrote:
DM wrote:
Hi All,

PST time changing tonight, I am not sure if this is going to affect the dat= abase....
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 processe= s that assume conventions from previous PG versions. For example:

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

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

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


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

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

select now()-'2 days'::interval;
=A0 =A0 =A0 =A0 =A0?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 Yo= rk 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


--0016368e25cc2143900464bcc970--