Content-Type: text/plain;
  charset="iso-8859-1"
From: Josh Berkus <josh@agliodbs.com>
Reply-To: josh@agliodbs.com
Organization: Aglio Database Solutions
To: Tom Lane <tgl@sss.pgh.pa.us>, kenzoid@io.com
Subject: Re: Timezone issue with date_part
Date: Sat, 2 Nov 2002 13:21:44 -0800
Cc: pgsql-sql@postgresql.org
References: <20021102065654.GA8564@roark.kenzoid.com>
	<20169.1036246634@sss.pgh.pa.us>
In-Reply-To: <20169.1036246634@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Message-Id: <200211021321.44211.josh@agliodbs.com>


Tom,

> (IMHO, the SQL spec is really brain-dead to define timestamp without
> time zone as the default form of timestamp; the variant with time zone
> is much more useful for most applications.  It's far too easy to shoot
> yourself in the foot when working with zoneless timestamps --- usually
> in a way that you won't notice until daylight-savings transition time
> comes around, or you roll out the app to users in other time zones.)

It's pretty easy to shoot yourself in the foot with time zones, as well.   =
For=20
example, most people are thrown off by the daylight-savings-time shift in=
=20
date calculations; for example:

 select '2002-10-20 00:00:00 PDT'::TIMESTAMPTZ + '2 weeks'::INTERVAL
jwnet-> ;
        ?column?
------------------------
 2002-11-02 23:00:00-08

This sort of behavior can really muck with calendar applications.  Of cours=
e,=20
it could be solved with a DAY/WEEK subtype, but I've already advocated for=
=20
that.

--=20

-Josh Berkus
 Aglio Database Solutions
 San Francisco