I think though that the majority of uses for a rules engine is in a business
context, where they don't use astronomical time.
If the doctor's orders are:
"You cannot get out of bed for 2 months"
This means 59 days if he told you February 1st, and it means 62 days if he
told you July 1st.
This is a particularly bad example, because doctors can't say that - at
least not one I'd trust ;-)
I'm arguing that you cannot expect a computer program to relieve you from
the burden of defining what you mean by a "duration of one year" (or month).
Some legal rules require a person to have a certain age, and it is (for humans)
more convenient to decide this on a person's birthday YMD plus an increment
in the Y number. If your application requires you to use an increment in the year
component of the YMDhms representation of a point in time, then you are
indeed stuck with Calendar and the resulting overhead. (Memoizing
the results of YMDhms +/- n years might speed things up, for the usual
price.)
But many applications would be satisfied with using a fixed duration for
a year in terms of 365 or 365.25 or some such value. If, for instance, you
have a library, and you must decide to move a book into deep storage
"if it has not been requested for more than a year" you might calculate
this (faster) by adding 356*24*60*60 to the clock value of the last return.
-W
So at least for me, I am going to have to work out a plan that involves
GregorianCalendar.
--
View this message in context: http://n3.nabble.com/AGE-problem-tp215215p354847.html
Sent from the Drools - User mailing list archive at Nabble.com.