Hi,
While making tests process execution tests I noticed that late timer job executions are performed in 'current' time (as process engine configuration clock have) and not in timer scheduled time. This means that relative times (like due date) are calculated not as read from process definition, but rather when jobs are executed.
For example, lets say there is simple process definition with single timer catching event leading to user task with relative due date (PT1H, 1 hour duration). When testing, clock is changed to be 3 minutes past timer due date. Calculated due date in resulting task will have value of timer due date + 1 hour + 3 minutes. Just from reading process definition, one would assume that user task due date will always be timer due date + 1 hour, but this is not the case.
And this is not a result of a bug, there's nowhere in TimerEntity which handles this situation. Even more, when clock is set in large increments, repeating timer events are calculated from current clock state rather than previous timer occurrence. This means that timer with cycle 1 hour can be executed ex. once every 90 minutes, if clock increments are large enough.
Even in production, when 'real', 'wall clock' is used, this will cause problems - in previous process example due date might be few seconds after what we could assume, depending on when job executor processes timer job.
I'd like know if this is intended behaviour, or if it's indeed a bug.
Resolution to this problem could be to set clock to timer due date at the beginning of TimerEntity.execute and restore current date at the end.
