RE: [Joda-interest] compareTo for Period

[Al M. <al...@bo...>]

a small clarification. i was a little loose in my usage of terminology in
the previous post. i don't really care if the comparison is implemented as a
method of Period, a separate class (like DateComparator) or even (ugh) a
separate global method.

as a matter of fact, the actual comparison method should not be an
implementation of Comparable:compareTo. the Comparable javadoc
(http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Comparable.html) states
that it defines a total order, whereas the period comparison definitely
defines a partial order.

however, it appears that certain implementations (egs.
http://workshop.bea.com/xmlbeans/reference/com/bea/xml/XmlObject.html) use
this interface to define partial orders with an exception when the objects
are not comparable. i don't think this is the right way to handle this
situation, and it doesn't cover the <= and >= cases in any case.

the java collections doc doesn't seem to define an interface for partial
orders.  later this week, i'll do a little research with google to see if
there's a canonical interface for partial orders. if anyone already knows
the right interface for this, please do post.

regards,

al


-----Original Message-----
From: jod...@li...
[mailto:jod...@li...]On Behalf Of Al Major
Sent: Saturday, November 27, 2004 9:15 AM
To: jod...@li...
Subject: [Joda-interest] compareTo for Period


hey steven,

	one quick point to follow up on my earlier email to you. i thought about it
some more. i'm posting to the list because others may have opinions on this.

	during the conversion from 0.96 to 0.98, i had to write a helper function
to convert period to duration. although i didn't say so, ultimately the
purpose was to compare the lengths of two periods, which was needed by the
application.

	i guess this is an argument to have a "compareTo" method for periods. this
was a real use-case, not an invented strawman. it's possible that others may
see a similar need arise at some point.

	this might seem nonsensical given that a period doesn't have a fixed
duration, but in many cases it's a reasonable question to ask and a precise
answer is feasible.

	for instance, in the gregorian calendar, weeks, days, hours, etc. are all
fixed length. so only months (and leap years/centuries) cause problems, but
even so there are known orderings.

	for example, 1 day is always less than 1 week is always less than 1 month
is always less than 1 year.

	for complex periods, we have a partial order, many (most) period lengths
are ordered relative to each other (some periods, the minority, are not
directly comparable).

	to determine ordering, what we have to do is convert variable length
periods to a range of fixed length periods. so, for months we know that 28
days <= 1 month <= 31 days. and 365 days <= 1year <= 366 days.

	we can then naively say that 56 days <= 2 months <= 62 days, 84 days <= 3
months <= 93 days (we can actually get a little more sophisticated as i'll
point out below)

	now, if we're asked to compare a period P1 of 5 weeks 3 days, with a period
P2 of 1 month 5 days. we do the following calculations

	P1:  5 Weeks 3 Days = 35 + 3 = 38 days.
	P2: 28 + 5 <= 1 month 5 days <= 31 + 5
	33 days <= 1 month 5 days <= 36 days

i.e. 33 <= P2 <= 36 < 38 = P1.

	so P2 < P1.

	however, if P1 had been 5 weeks, i.e. 35 days, P1 and P2 would not be
ordered relative to each other.

	i'd like to argue that compareTo should be implemented in the library with
return values <, <=, =, >, >=, and INCOMPARABLE. it's very hard to do it
_correctly_ in user code, because it's calendar-specific and tedious
(error-prone). precisely the kind of thing to put into a date/time library.

	the code i wrote didn't do an exact range calculation and partial order, it
was a quick'n'dirty approximation using 30 day months and 365 day years. i
wouldn't advocate its inclusion in the library because it will give
incorrect results at times (fortunately not in my app).

	to finish up, we can get a little more sophisticated than the above, and
actually count the minimum and maximum days for all multi month periods in
any year. i.e. since feb can only come once a year, we cannot have 2 28 day
months follow each other. jan and mar both have 31 days. thus the minimum
number of days in a 2 month period is not 56 but 59 (28 + 31 = 59). the
maximum is still 62 (dec/jan). with this more precise calculation

	59 days <= 2 months <= 62.

	we can continue this for 3 months, 4 months, etc to 12 months (after 12, we
start using Years and Months).

	i know 1.0 is close. i don't know how many other people have a similar
need, and whether it's best delayed till after 1.0. but i'd strong argue for
its inclusion at some point.

regards,

al



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
Joda-interest mailing list
Jod...@li...
https://lists.sourceforge.net/lists/listinfo/joda-interest