Andrew Gierth <and...@tao11.riddles.org.uk> wrote: >>>>>> ""Kevin" == "Kevin Grittner" <kevin.gritt...@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
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
