Lists Home |
Date Index |
Perhaps there is an analogy between pinning and some aspect rounding of
floating point computations.
It seems there's something wrong with the pinning algorithm. Probably,
there should be an attempt to do pinning only at the end of the computation
(by analogy with rounding) -- the idea of pinning to a valid date after
adding Y/M components, then later dealing with the day and time parts seems
of dubious merit.
Other examples of difficulty:
1. Two datetimes can swap their order after each incrementing by the same
2004-02-28T23:59 < 2002-02-29T00:00
2004-02-28T23:59 + P(1Y1D) > 2004-02-29T00:00 + P(1Y1D)
since these are
2005-03-01T23:59 and 2005-03-01T00:00 respectively.
2. Given dates x and y and duration d
(x+d) - (y+d) does not equal (x - y) in some pathological cases, like the
----- Original Message -----
From: "Jeni Tennison" <firstname.lastname@example.org>
To: "Jeff Greif" <email@example.com>
Sent: Sunday, September 29, 2002 2:50 PM
Subject: Re: [xml-dev] limits of the generic
> Hi Jeff,
> > Yes, the comparison of these durations is determinate. However, it
> > is inconsistent with
> > 2004-02-29 + P1Y1D > 2004-02-29 + P365D
> > which is false according to the algorithm you described, (but would
> > be true for any starting date which is not 02-29 in a leap year). In
> > other words, I cannot deduce from x > y (P1Y1D > P365D) that a + x >
> > a + y. I realize its a different > operator (for durations vs.
> > dates), but if they are not defined consistently there is a problem.
> Ah, I see what you mean. It's not just a problem with xs:durations,
> though, rather a problem whenever there's "pinning" of the dates back
> to valid values. For example, even if you're just looking at
> xf:yearMonthDurations, you'd expect:
> (2002-08-31 + P1M) + P1M
> to be equal to:
> 2002-08-31 + (P1M + P1M)
> but (according to the algorithm in the Datatypes Rec.):
> (2002-08-31 + P1M) + P1M => 2002-09-30 + P1M => 2002-10-30
> 2002-08-31 + (P1M + P1M) => 2002-08-31 + P2M => 2002-10-31