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
example, most people are thrown off by the daylight-savings-time shift in
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 course,
it could be solved with a DAY/WEEK subtype, but I've already advocated for
that.
--
-Josh BerkusAglio Database SolutionsSan Francisco
