-
Notifications
You must be signed in to change notification settings - Fork 566
Timezone problem on getAttendeesAvailability CalendarEvent #88
Description
When retrieving FreeBusy data using ExchangeService.getUserAvailability() the StartTime and EndTime of each CalendarEvent in the results are returned as UTC values even if the ExchangeService was constructed with a specific TimeZone.
The method readElementValueAsUnbiasedDateTimeScopedToServiceTimeZone() of EwsServiceXmlReader is used to convert these UTC strings to Date objects,
however at some point the DateFormat has had its TimeZone set to the default by commenting out line 108. (formatter.setTimeZone(TimeZone.getTimeZone("UTC"));)
This causes the UTC string to be parsed as a local Date. so in the UK during British Summer Time the String "2014-10-06T12:00:00" becomes the Date 2014-10-06T12:00:00+0100 which is 2014-10-06T11:00:00Z i.e. one hour out.
for dates in standard time there is no problem in the UK as UTC == GMT so the conversion has no effect.
removing the comment on line 108 (and I suggest 114) solves the problem in that the Date returned is in UTC and can be converted to local time as required. So "2014-10-06T12:00:00" becomes the Date 2014-10-06T12:00:00Z which is 2014-10-06T13:00:00+0100
My suggested fix is as follows:
public Date readElementValueAsUnbiasedDateTimeScopedToServiceTimeZone()
throws Exception {
// Convert the element's value to a DateTime with no adjustment.
String date = this.readElementValue();
Date tempDate = null;
try {
DateFormat formatter =
new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss");
formatter.setTimeZone(TimeZone.getTimeZone("UTC"));
tempDate = formatter.parse(date);
} catch (Exception e) {
DateFormat formatter = new SimpleDateFormat(
"yyyy-MM-dd'T'HH:mm:ss.SSS");
formatter.setTimeZone(TimeZone.getTimeZone("UTC"));
tempDate = formatter.parse(date);
}
return tempDate;
}
However, it may be worth reviewing the code to make use of either the ExchangeService TimeZone or the WorkingHours TimeZone from the response