Re: [rules-users] AGE problem

From: Jason Smith <jsmith(a)infotrustgroup.com&gt; Subject: Re: [rules-users] AGE problem To: "Rules Users List" <rules-users(a)lists.jboss.org&gt; Date: Tuesday, February 23, 2010, 7:45 AM Hey, I haven't been following this thread, but you can use Joda Time to get much better, easier results.  For instance, you can add 1 month to a DateTime by using a new Period("P1M") [that is, a period of 1 month] - all done according to ISO8601 standards, so it works flawlessly, including adjustments for things like daylight savings time (so you don't have to think about it much). In business, we live and die by precise time calculations.  Think of it as being like a check writing program that "estimates" a salary, and then pays the employee that amount.  Get your torches and pitchforks! Jason Smith ________________________________________ From: rules-users-bounces(a)lists.jboss.org [rules-users-bounces(a)lists.jboss.org] On Behalf Of Pavel Tavoda [pavel.tavoda(a)gmail.com] Sent: Tuesday, February 23, 2010 1:30 AM To: Rules Users List Subject: Re: [rules-users] AGE problem Try to do this in bank application. People come 1 hour after they date expired and try to charge them for sooner withdrawal because you calculate with 365.25 not 365 days. You will be kicked, believe me. Pavel 2010/2/23 Wolfgang Laun <wolfgang.laun(a)gmail.com&gt;: > On Tue, Feb 23, 2010 at 8:07 AM, djb <dbrownell83(a)hotmail.com&gt; wrote: >> >> 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. >> _______________________________________________ >> rules-users mailing list >> rules-users(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/rules-users > > > _______________________________________________ > rules-users mailing list > rules-users(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users > > _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users