Re: [rules-users] AGE problem

On Tue, Feb 23, 2010 at 8:07 AM, djb <dbrownell83(a)hotmail.com&gt; wrote: 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