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.