ACT-1836: AdvancedCycleBusinessCalendar can handle instances where the scheduled time zone is different from the server time zone and can handle daylight saving time accordingly.

This new cycle business calendar is able to handle instances where an instance's scheduled time zone is different than the server time zone. In our case all servers run on UTC but we want to schedule workflows to run in US/Eastern (or any time zone in the world).

Activiti used to do all scheduling using java.util.Date objects. Date objects do not save time zone information, only UTC offset. Offset is useless for calculating DST because two time zones may have the same offset, but only one observes DST. It is impossible to tell which the user meant in this case. Also, CRON strings don't even include the UTC offset.

The solution is to switch CronExpression and DurationHelper to use Calendar objects which include the time zone. When you pass a Calendar to a getTimeAfter method, it will do the calculation using the Calendar's time zone.

ClockUtil was also enhanced to use Calendars.

AdvancedCycleBusinessCalendar is a replacement that uses a new field in the schedule string (DSTZONE:zone ID) to determine how to handle scheduling. Leaving it out defaults to the old way of using the server's time zone.

It also versions schedule strings for backwards compatibility.

New unit tests are included. "mvn -Pcheck clean install" ran successfully.

Documentation for use is in AdvancedCycleBusinessCalendar.java

This is not the default cycle business calendar, it must be specified in your process engine configuration. This is done through a helper factory SpringAdvancedBusinessCalendarManagerFactory (usage is documented in source)  It should be backwards compatible so it could replace CycleBusinessCalendar, I'll leave that up to you :)