order relation of timeDuration

> Then, the order-relation of two timeDuration values x and y is x > y
> iff x[s] > y[s] for any starting instant s, x < y iff x[s] < y[s] for
> any s and x = y iff x[s] = y[s] for any s. 

This looks like a too much burden for the implementation.

> P1M20D and P50D is indeterminate

The aboe example shown in the section 3.2.6 of the spec is a trivial one.

For example,

P28D <= P1M <= P31D

( This inequality means P27D<P1M but P28D?P1M. '?' here means
"indeterminate" )


P59D <= P2M <= P62D

because there are no two consecutive months of 28 days, whereas there
ARE two consecutive months of 31 days (Dec&Jan).

P89D <= P3M <= P92D

And it goes in this way.

What shall I do if I am asked to fill in the following blanks?

P___D <= P1923526M <= P___D

You have to even consider the leap years!

The bottom line is that this definition of order relation is almost
impossible to implement.

My alternative suggestion is this.

1. the value space of timeDuration is two-dimensional space of decimal.
   One is the number of months and the other is the number of days.
   I use (m,d) pair to designate this value.

   This means 1 year is always 12 months, 1 day is always 24 hours,
   1 hour is always 60 minutes, and 1 minute is always 60 seconds.
   As long as this restriction is clearly stated, of course we can
   think the value space as six-dimensional space of decimal.

   Actually 1 minute is not always 60 seconds (the leap second), but
   it introduces a further complication to the spec.

2. (m1,d1) < (m2,d2) iff m1*31+d1<m2*28+d2
   (m1,d1) = (m2,d2) iff m1=m2 and d1=d2
   (m1,d1) > (m2,d2) iff (m2,d2)<(m1,d1)

The relationship is still a partial order, but at least the
implementation is simple.

And the spec doesn't mention the canonical representation of

E-Mail: k-kawa@bigfoot.com

Received on Tuesday, 30 January 2001 17:42:13 UTC