From: | Josh Berkus <josh(at)agliodbs(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Cc: | Dennis Bjorklund <db(at)zigo(dot)dhs(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: timestamp with time zone a la sql99 |
Date: | 2004-10-25 18:54:33 |
Message-ID: | 200410251154.33532.josh@agliodbs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Dennis,
> It doesn't discuss it. According to the spec a timestamp with time zone is
> a UTC value + a HH:MM offset from GMT. And intervals in the spec is either
> a year-month value or a day-time value. One can only compare year-month
> values with each other and day-time values with each other. So they avoid
> the problem of the how many days is a month by not allowing it.
That's not what Tom and I were talking about. The issue is that the spec
defines Days/Weeks as being an agglomeration of hours and not an atomic
entity like Months/Years are. This leads to some wierd and
calendar-breaking behavior when combined with DST, for example:
template1=> select '2004-10-09 10:00 PDT'::TIMESTAMPTZ + '45 days'::INTERVAL
template1-> ;
?column?
------------------------
2004-11-23 09:00:00-08
(1 row)
Because of the DST shift, you get an hour shift which is most decidely not
anything real human beings would expect from a calendar. The answer is to
try-partition INTERVAL values, as:
Hour/Minute/Second/ms
Day/Week
Month/Year
However, this could be considered to break the spec; certainly Thomas thought
it did. My defense is that the SQL committee made some mistakes, and
interval is a big one.
--
--Josh
Josh Berkus
Aglio Database Solutions
San Francisco
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-10-25 19:04:16 | Re: timestamp with time zone a la sql99 |
Previous Message | Dennis Bjorklund | 2004-10-25 18:26:59 | Re: timestamp with time zone a la sql99 |