Re: [rules-users] AGE problem
I was about to suggest this. :) And one advantage of using joda time is that
version 1.6 is already included as a dependency of drools.
--- On Tue, 2/23/10, Jason Smith wrote:
> From: Jason Smith
> Subject: Re: [rules-users] AGE problem
> To: "Rules Users List"
> 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-boun...@lists.jboss.org
> [rules-users-boun...@lists.jboss.org]
> On Behalf Of Pavel Tavoda [pavel.tav...@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 :
> > On Tue, Feb 23, 2010 at 8:07 AM, djb
> 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@lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/rules-users
> >
> >
> > ___
> > rules-users mailing list
> > rules-users@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/rules-users
> >
> >
>
> ___
> rules-users mailing list
> rules-users@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
> ___
> rules-users mailing list
> rules-users@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] AGE problem
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-boun...@lists.jboss.org [rules-users-boun...@lists.jboss.org]
On Behalf Of Pavel Tavoda [pavel.tav...@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 :
> On Tue, Feb 23, 2010 at 8:07 AM, djb 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@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
> ___
> rules-users mailing list
> rules-users@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
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 : > On Tue, Feb 23, 2010 at 8:07 AM, djb 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@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/rules-users > > > ___ > rules-users mailing list > rules-users@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users > > ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] AGE problem
On Tue, Feb 23, 2010 at 8:07 AM, djb 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@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users > ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] AGE problem
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. 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@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] AGE problem
For representing times, there are two distinct data types:
- absolute time, as a sequence of points on a timeline (the real "Time");
- durations, which are differences between points on a timeline.
Absolute time can be represented in a number of ways:
- as seconds (or milliseconds or nanoseconds), with 0 being some agreed-upon
point in Time,
- by Y,M,D,h,m,s according to some calendar;
- as Julian Days, in fractions.
It's obvious that calculations of any kind are best done with one of the
single-valued representations.
Durations can be expressed in any convenient unit, as long as there is a
well-defined conversion between the units with which you represent absolute
time and the units you desire to express durations.
There is no such well-defined conversion for (months and) years, and
therefore the idea to express a duration (precisely) in years is not used
commonly. (Astronomers settle for a year being equal to 365.25 Julian days;
so if this suits you, go ahead and base your calculations on that.)
For efficiency in rules, you might consider using Date.getTime() (or
Calendar.getTimeInMillis()) to obtain a point on the timeline, and to
express your notion of a year's duration (whatever it is) in the suitable
unit, and to use this for comparisons.
-W
On Thu, Feb 18, 2010 at 1:43 PM, Pavel Tavoda wrote:
> Hello,
> I would like to calculate AGE of object based on Date inside object, I
> can use eval but I hope it's so basic functionality that Drools should
> have it. It's also performance problem if I need to use EVAL in many
> rules (let's say 100 in XLS). I'm playing with some FUSION features
> like:
> $now : Now() && $order : SecurityOrder(this before[400d, 0d] $now)
> should work but I can't specify YEARS as constant. That's a problem
> for long time because 30*365d isn't same as 30 years if you consider
> leap years. Is it possible some easy way to calculate AGE of something
> with correct time handling and compare to years? Something like:
>SecurityOrder( age(createdDate) > 20y, age(createdDate) < 25y)
> or by FUSION:
> $now : Now() && $order : SecurityOrder(this before[25y, 20y] $now)
>
> For now I'm using following function in eval() but it's becoming
> performance problem:
> function boolean between(Calendar currentDate, Date oldDate, int from, int
> to) {
>Calendar fromCal = Calendar.getInstance();
>fromCal.setTime(oldDate);
>fromCal.add(Calendar.YEAR, from);
>
>Calendar toCal = Calendar.getInstance();
>toCal.setTime(oldDate);
>toCal.add(Calendar.YEAR, to);
>return currentDate.after(fromCal) && currentDate.before(toCal);
> }
>
> Thank you
>
> Pavel
> ___
> rules-users mailing list
> rules-users@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] AGE problem
I am also interested in this, though my requirement specifies DAY/WEEK/MONTH/YEAR, so it's a bit more complex. It appears from the documentation that the way to compare dates without an eval is: Cheese( bestBefore < "27-Oct-2009" ) So, i reckon... a function that subtracts a number of years/months/weeks/days using GregorianCalendar and returns a date, can be compared with, in your case, $now, provided that it is a String in that form. But I'll work on it in the meantime, and get back to you if I work out something. Please let me know if you work out something without eval() too, thanks. -- View this message in context: http://n3.nabble.com/AGE-problem-tp215215p326884.html Sent from the Drools - User mailing list archive at Nabble.com. ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
[rules-users] AGE problem
Hello,
I would like to calculate AGE of object based on Date inside object, I
can use eval but I hope it's so basic functionality that Drools should
have it. It's also performance problem if I need to use EVAL in many
rules (let's say 100 in XLS). I'm playing with some FUSION features
like:
$now : Now() && $order : SecurityOrder(this before[400d, 0d] $now)
should work but I can't specify YEARS as constant. That's a problem
for long time because 30*365d isn't same as 30 years if you consider
leap years. Is it possible some easy way to calculate AGE of something
with correct time handling and compare to years? Something like:
SecurityOrder( age(createdDate) > 20y, age(createdDate) < 25y)
or by FUSION:
$now : Now() && $order : SecurityOrder(this before[25y, 20y] $now)
For now I'm using following function in eval() but it's becoming
performance problem:
function boolean between(Calendar currentDate, Date oldDate, int from, int to) {
Calendar fromCal = Calendar.getInstance();
fromCal.setTime(oldDate);
fromCal.add(Calendar.YEAR, from);
Calendar toCal = Calendar.getInstance();
toCal.setTime(oldDate);
toCal.add(Calendar.YEAR, to);
return currentDate.after(fromCal) && currentDate.before(toCal);
}
Thank you
Pavel
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
