Re: timestamp with time zone a la sql99

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Dennis Bjorklund <db(at)zigo(dot)dhs(dot)org>
Cc: Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: timestamp with time zone a la sql99
Date: 2004-10-25 19:35:04
Message-ID: 22816.1098732904@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Dennis Bjorklund <db(at)zigo(dot)dhs(dot)org> writes:
> The standard treat days as a separate entry, it does not assume that a day
> is 24 hours.

SQL92 says

4.5.2 Intervals

There are two classes of intervals. One class, called year-month
intervals, has an express or implied datetime precision that in-
cludes no fields other than YEAR and MONTH, though not both are
required. The other class, called day-time intervals, has an ex-
press or implied interval precision that can include any fields
other than YEAR or MONTH.

AFAICS the reason for this rule is that they expect all Y/M intervals to
be comparable (which they are) and they also expect all D/H/M/S intervals
to be comparable, which you can only do by assuming that 1 D == 24 H.

It seems to me though that we can store days separately and do interval
comparisons with the assumption 1 D == 24 H, and be perfectly
SQL-compatible as far as that goes, and still make good use of the
separate day info when adding to a timestamptz that has a DST-aware
timezone. In a non-DST-aware timezone the addition will act the same as
if we weren't distinguishing days from h/m/s. Therefore, an application
using only the spec-defined features (ie, only fixed-numeric-offset
timezones) will see no deviation from the spec behavior.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruno Wolff III 2004-10-25 19:40:57 Re: timestamp with time zone a la sql99
Previous Message Dennis Bjorklund 2004-10-25 19:18:52 Re: timestamp with time zone a la sql99