Server default timezone can be incorrect

Steps to reproduce

Seen in server logs:

2017-03-09 09:44:38,771 | WARN | qtp943789296-23335 | (AbstractEventEndpoint:1623) - No 'capture.device.timezone' set on agent hoerilt1. The default server timezone Africa/Maseru will be used.

2017-03-09 09:48:58,191 | WARN | qtp943789296-23311 | (AbstractEventEndpoint:1623) - No 'capture.device.timezone' set on agent alex1c. The default server timezone UTC will be used.

This is logged in the getNewConflicts() method. At 9:44, the correct timezone is used, and at 9:48 the wrong timezone is used.

The default timezone is from:


which is java.util.TimeZone.

We find elsewhere in the code, the default is being temporarily set to UTC here:

matterhorn-index-service/src/main/java/org/opencastproject/index/service/impl/ TimeZone.setDefault(utc);

and here:

matterhorn-scheduler-impl/src/main/java/org/opencastproject/scheduler/impl/ TimeZone.setDefault(utc);

both in the calculatePeriods() method - not sure why that code is duplicated.

As the default is server-wide, changing the default timezone is not safe, because if this runs concurrently with another thread that relies on the default timezone, the second thread would get the wrong timezone.


Stephen Marquard
March 11, 2017, 9:31 PM

I wonder if we could replace this code with ical4j methods. We have a very old ical4j patched version (see ) which is


and the latest is 2.0.0. Perhaps we could use

Greg Logan
April 19, 2017, 8:45 AM


Can you try and keep track of this through the merge of the Extron scheduler? Some of the old code you mentioned might just go away, which would be a nice fix.

Stephen Marquard
April 19, 2017, 7:42 PM

Created so we don't lose this issue.

Fixed and reviewed




Stephen Marquard


Incorrectly Functioning Without Workaround

Tags (folksonomy)



Fix versions

Affects versions