Hi Adrian, seems to work with me and derby configured. Only meeting in log

org.ofbiz.base.conversion.ConversionException: java.text.ParseException: Unparseable date: "1446418800000 00:00:00.000"

when i go to next or previous month (swithing month actually works).

You may meet a db related issue ?

Works with postgres on my local environment either...

The problem exists on my local unmodified copy, and it also exists on the demo site.

It might be caused by having a recurring work effort that uses a temporal expression.

Good catch ! The daily Grind test are the origin of the problem !

I did some more analysis around this issue, i may have found an irregularity about temporal expression.

The issue come when evaluating DAiLY_GRIND temporal expression, which is and intersection of daily 8am rule, and monday to friday without US federal holidays rule.

First is evaluated the smallest unit of time i.e. 8am rule. The next() method will find its way easily, but... it's might be a day after, and in the ExpressionContext, dayBumped value is set to "true".

The inifinite loop come from the second rule next() method, which is a difference working on a day on week basis.

public Calendar next(Calendar cal, ExpressionContext context) {
Calendar next = (Calendar) cal.clone();
if (includesDate(next)) {
if (context.dayBumped)

next method return itself if dayBumped is set to true. Fine for the first time, bad for the next leading to an infinite loop.

The patch I provide is simple and seems the good way to fix it.

Then inifinite loop will not appear with a daily_grind recurrent workeffort.

I find out that the calendar have a strange behaviour displaying my recurrent workeffort, i will continue studying it to see if the origin is this fix (i don't think so)...

Thank you for working on this!

My pleasure !

I confirm the fix is good for the endless loop and is quite logic. If a previous rule trigger the dayBump flag, bypassing day increment should revert the flag to false.
The strange behaviour seems to be a separated bug i will describe in another Jira (getWorkEffortEventsByPeriod service)

Thanks Adrian for reporting the Bug

With emotion my first commits fixed it in :

trunk r1707782
release14.12 r1707784
release13.07 r1707785
release12.04 r1707786