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 Berkus
Aglio Database Solutions
San Francisco
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
