I've found the source of the problems dealing with timezones and DST.
In GooCalUtil.convXSToNotesDateTime, a string is parsed into components, one of which is the numeric timezone offset. In my case, this offset is GMT-5.00, corresponding to the Eastern time zone in the United states.
The code
String tzStr = org.substring(19, 22);
if (tzStr.charAt(0)=='+') {<br/>
tzStr = tzStr.substring(1, 3);<br/>
}<br/>
correctly identifies the tz offset as -05.
However, the following code:
int tzOffset = Integer.parseInt(tzStr) * 60 * 60 * 1000;<br/>
TimeZone tz = TimeZone.getTimeZone(java.util.TimeZone.getAvailableIDs(tzOffset)[0]);<br/>
does the wrong thing. java.util.TimeZone.getAvailableIDs returns a list of all timezone ids at -05. The first element of this list corresponds to the timezone "America/Atikokan", which is not currently using DST, while the correct Timezone id would correspond to "US/Eastern" or "America/New York" which is using DST.
Depending on the order of timezone id entries in the list, this could produce calendar times for meetings scheduled in a different timezone which are off by 0, 1, or 2 hours.
Therefore, one cannot simply use the first returned element of ava.util.TimeZone.getAvailableIDs to get a timezone id.
Since lotus stores/returns a string which must be parsed as a string, and not a timezone id, I believe the only solution
is to have a configuration file which GooCalSync will
use to map from a numeric timezone offset to a timezone id.
This file could be pre-configured for the timezone ids for the largest population centers, and users who are in an "unusual" timezone could edit it to match.
For instance:
-05 America/New York
-06 America/Chicago
-07 America/Denver
-08 America/Los Angeles
I suppose other solutions are possible, but the using the first returned id is just wrong.
On the other hand, I suppose it's possible that lotus notes itself has a better idea of the exact timezone id, perhaps a better solution would be to modify
GooCalUtil.convNotesDateTimeToXS to take care of dst, since the passed-in lotus.domino.DateTime function does have an isDST function which is probably more accurate than converting to a string and back to a date object.