Thanks Edson for your reply, however I am still not clear about why the rule is firing if the time stamp of the event falls outside the time window. This can happen, for example, if the event originates in a machine with clock slightly ahead. I think the problem also occurs if the time is in the past; I would not want to take action on a future or old event. I understand that events are immutable, and I am not changing the event in any way. However, I expect the "sliding time window" to be changing along with the system clock until it reaches the timestamp of the event. My question still unanswered, why is the rule firing outside its time window? Is there a way to make this work? Any advice about how to address this use case? Thanks -- View this message in context: http://drools.46999.n3.nabble.com/Future-events-tp3826236p3826759.html Sent from the Drools: User forum mailing list archive at Nabble.com.

Well, yes that is how the engine works. But should it work this way? Why fire the rule if not in the appropriate time window? This still looks wrong to me, as the intention of the rule is not observed. On the per hand, the engine does queue events in other scenarios, so it seems arbritrary. Too bad because this would be a ver nice way to model scheduled events using the temporal operators. Thanks Edson -- View this message in context: http://drools.46999.n3.nabble.com/Future-events-tp3826236p3827065.html Sent from the Drools: User forum mailing list archive at Nabble.com.

laune wrote Correct, I want my application to handle this within the rule engine. This is why I don't want the rule to be fired if the timestamp is outside the time window. Exactly, and I should not send an alert message for an event that has long occurred, so I was hoping the rule engine to take care of this for me. I have a powerful temporal operator, so why not use it? There are two times here, the sliding time window, and the time of the event. The time responsible for sliding the time window is the system clock. However, the time of the event is dictated by the event's time stamp. The engine allows me to declare the event time stamp to be a data member of the event class: By providing this ability, the engine is implicitly promising me to use the time stamp from the event, as opposed to the time when the event is inserted in the working memory. I have now tested both future and past events and they both cause the rule to be fired regardless of the event's time stamp. The engine is clearly ignoring the time stamp as declared and using the insertion time stamp. If this is not a bug, then it is for sure very confusing, and perhaps needs to be clearly explained that the timestamp from the event is not taken into consideration by the sliding time window operator. Thanks, Alex -- View this message in context: http://drools.46999.n3.nabble.com/Future-events-tp3826236p3828674.html Sent from the Drools: User forum mailing list archive at Nabble.com.