Wolfgang Laun wrote:
> 2011/6/30
>
>> What are the available symbolics for temporal values?
>> That is, d is for days, m is for minutes, h is for hours, s is for
>> seconds.
>> Are there any other symbolics specifically for months and years?
>>
Thanks for the clarification.
>
> You can use ms fo
The times attempt to be ISO8601 compliant, for Hours and earlier.
Although I noticed that tidbit of information is missing for the docs,
we'll get it added. See TimeUtils
private static final Pattern SIMPLE = Pattern.compile(
"([+-])?((\\d+)[Dd])?\\s*((\\d+)[Hh])?\\s*((\\d+)[Mm])?\\s*((\\d+)[
2011/6/30
> What are the available symbolics for temporal values?
> That is, d is for days, m is for minutes, h is for hours, s is for seconds.
> Are there any other symbolics specifically for months and years?
>
You can use ms for millisecond. There are no universally acceptable duration
values
I am getting runtime exception with these temporal operator changes when I
compile the knowledge base using a knowledge agent. If I compile the drl
using:
KnowledgeBuilder kb =
KnowledgeBuilderFactory.newKnowledgeBuilder();
kb.add(ResourceFactory.newFileResource(pa
What are the available symbolics for temporal values?
That is, d is for days, m is for minutes, h is for hours, s is for seconds.
Are there any other symbolics specifically for months and years?
I haven't found any mentioning of them in the Fusion manual.
I'm using 5.0.1
Thank you,
-Stathis
Wolf
Thanks! I converted over to these and my tests are all passing so far.
Examples (snippets):
// > one day old
when
$step : Step(status == Status.ACTIVE, task.job.statuteOfLimitationsDate
!=
null)
Date($now : time) from Calendar.getInstance().getTime()
Date($solDate : time
Hi Steven,
I've been able to reproduce the bug and narrow down why and where it occurs.
Given a String property 'name' of some fact type, a constraint using "not
in" such as
$name: name not in ( "Joe", "Jack" )
fails. You can work around by avoiding the binding
name not in ( "Joe", "Jack
I find the spreadsheet and code you provided (with the typo on "agepe"
corrected) works exactly as expected.
I tried with both 5.2-Final and 5.1.1.
On 29 June 2011 12:38, GrooV wrote:
> It actually even seems to fail when I add a 2nd column with age < 65 and
> age
> > 18 in the first
>
> Genera
