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:
TimeZone.getDefault().getID();
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/IndexServiceImpl.java: TimeZone.setDefault(utc);
and here:
matterhorn-scheduler-impl/src/main/java/org/opencastproject/scheduler/impl/Util.java: 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.
I wonder if we could replace this code with ical4j methods. We have a very old ical4j patched version (see ) which is
<dependency>
<groupId>net.fortuna.ical4j</groupId>
<artifactId>ical4j</artifactId>
<version>1.0-rc2-patched</version>
</dependency>
and the latest is 2.0.0. Perhaps we could use
Hi
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.
Created so we don't lose this issue.