Andrew Gierth <andrew@tao11.riddles.org.uk> wrote:
>>>>>> ""Kevin" == "Kevin Grittner" <Kevin.Grittner@wicourts.gov>
> writes:
>
> Kevin> TIMESTAMP WITH TIME ZONE is not completely ANSI-compliant,
>
> Given that the spec requires that 2009-01-31 + interval 1 month =
> 2009-02-31 (yes, really! see general rule 4 in subsection 6.30), I
> think we can safely ignore virtually everything it says about
> date/time handling.
Codd went on at some length about why this is the right thing to do.
He was highly critical of systems where adding a month to a date and
then subtracting month from the result could result in a date which
was off from the original date by as much as three days. As a
mathematician he felt strongly that "(x + y) - y" should equal x --
even when x is a date and y is an interval.
Of course, you need to support the whole, coherent set of operations
for it to make sense; if you take this particular operation out of
context and put it together with other operations which don't follow
his coherent set of rules, it does look silly. Treating stored
dates as an abstraction which is mapped to the actual calendar as
needed is different, but hardly foolish. Such features would make
it a bit easier for software, for example, to properly handle a
court order that someone make an initial payment on a given date
(say January 30th) and then the same day of each subsequent month
until the amount is paid in full.
From what review I've done of it, it holds together as a complete
system; the question is how many little bits and pieces can be
adopted into a fundamentally different system and still have them
make sense. Personally, I think that including time zone in the
TIMESTAMP WITH TIME ZONE data type would go a long way toward making
some useful features work.
-Kevin
